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ABSTRACT 


In terms of manpower, time and money, (axe Single largest 
investment that must be made in the acquisition and 
maintenance of a targe and complex computer system is the 
investment made in software. In response to this situation, 
the DOD began an intensive and comprehensive research and 
development effort in an attemot to reduce, if not eliminate 
the inherent problems associated with software system design. 

mr the end cesult of this effort was tne creation of tne Ada 


programming language. This thesis will examine thre 
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development of thelanguage, focusing attention on the 


concepts and features wnich make Ada a potential "software 
Sekois — Solution. These concepts and features will be 
furtner examined as to the extent to which they support the 


utilization of Ada as a program design language (PDL). 
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I. INTRODUCTION: BRIEF HISTORY OF THE DEVELOPMENT OF ADA 


A. BACKGROUND: THE SOFTWARE CRISIS 

In terms of manpower, time and money, the single largest 
investment that must be made in the acquisition and 
maintenance of a large and complex computer System is cne 
investment made in software. pas ra amine 2 rine or years 
the cost per executed instruction of computer hardware has 
declined by a factor of two every two to three vears;: while 
Miewaepative COSt Of SOftware Nas increased dramatwenely, 
meeonmmeenaew cus Or tOtal computing costs in 1960 to cover 80% 
Smmenese COscs in 19890. The increasing ratio of software ¢to 
Nardware costs is most acutely demonstrated in comolex 


emoedded computer systems SOURCES ae ana USed Sia en= 
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Devartment of Defense. In 1973 over 50% of the DOD's total 
software expenditures were dedicated to embedded systems, and 
today that figure is significantly picherw Weoupled Wile eenis 
is the fact that complex embedded software projects have 
Frequentiy experienced substantial cost and schedule overruns 
and have sometimes had to be abandoned altogether because 
tneir sheer complexity resulted in project attempts which 
oecame altogether unmanageable [Ref. 1: p. 6]. 

The term "software crisis" was coined in the late sixties 


to describe what was becoming a wholly untenable situation. 


Thousands of programmers and analysts using hundreds of 





languages for use on Nundreds of computers with untold 
VermiarEonseim applications resulted in an overall software 
Dicture within DOD that was simply beyond comprehension, let 
alone management. In response to this situation, the DOD 
began in 1975 what was to become one of the most 
comprehensive and forward looking programs in the history of 
software engineering--the development of the Ada language 
eet. 2). 

Pe crmmtOmlI/2—60t waS reaiized within DOD tnat one of the 
greatest problems afflicting the management and uses of 
Sempteer SClSware “was  cenas there were simply too many 
Mm ©£femen: software languages in use (roughly 400, counting 
Memmi gtJuages ana Qialects in use a= that tine). The great 
diversity of languages in use, coupled with the wide varisaty 
of apelications required by DOD embedded software systems, 
resulted in the fact that portability of software oetween 
Systems was in most cases impossible. Additionally, since 
DOD embedded systems tended to ve very complex, each svstem 
tendea to become an island unto itself regarding the svstem's 
acquisition, maintenance and personnel support resulting in 


tne need for specialized toois and versonnel training for 


each system. 


B. THE HIGH ORDER LANGUAGE WORKING GROUP 


The multiple language problem begaqed as its logical 


panacea the formulation or adoption of a single software 
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language which could be utilized on all embedded system 
software applications. The DOD reasoned that -if-a universal 
language could Seca, substantial gains in the control 
over such problems as non-portability, extensive maintenance 
and, Programmer training expenditures, and software 
understandability, |could be- achieved. To address the problem 
of multiple languages, as well as to attempt a reasonable 
solution to that problem, the High Order Language Working 
Group (HOLWG) was formed in 1975 with reoresentatives from 
the Army, Navy, Air Force, Marines and other Defense 
agencies. The HOLWG's charter was to explore and identify 
the DOD's requirements for computer programming languaces, 
evaluate existing languages then being used by the DOD, and 
finally to recommend the implementation and control of a 
"Minimal set" of languages for use throughout the DOD. 
During 1975 and 1976, HOLWG undertook an extensive require- 
ments analysis process in accordance with its charter, 
beginning with the publication of STRAWMAN, which was essen- 
tially a questionnaire with which to stimulate comments from 
the field. In August of 1975 the WOODENMAN document was 
Written which summarized the comments and recommendations 
received through STRAWMAN. Further solicitation of comments 
from worldwide sources followed, and the results were again 


analyzed, leading up to the publication of TINMAN, which was 


te 





Baeomebeceonset OL requirements for the intended universal 
language. 

The research up to this point had revealed that though 
the differences in embedded system software applications were 
substantial, the programming language requirements for a 
broad spectrum of those applications were remarkably similar. 
Pe was, £Or instance, clear that for all applications, such 
orogramming methodology attributes as top-down design, 
Structured programming and information hiding were desirable 
features to utilize as these features enhanced management's 
ability £0 improve vrogrammer productivity, system 
Peewee elaty and overall system control. In addition these 
Features were seen as essential toward making possibie the 
Gevelooment of advanced Dorogramming tools with the votential 
Semcwoneercantly 2mprove the productivity of DOD software 
engineers. 

The publication of TINMAN in January of 1976 was followed 
by an intensive examination of existing languages, and a 
formal evaluation of those languages against the requirements 
spelled out in TINMAN. As might be expected, no single 
existing language was found acceptable as meeting those 
requirements. The primary reason for this is that each 
language was irretrievably entangled within the application 


it supported, and in most cases the different languages and 
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eateers were initially designed for a specific application, 
and only later applied to a broader applications base. 
“Although no existing language was recognized as being 
capable of adopticn as a universal DOD computer language, the 
HOLWG did recognize an immediate need to stop the prolifera- 
Prem OL mewer, Ehougn tée@hnically similar languages in the 
acquisition and maintenance of embedded system software pro- 
jects. In April of 1976 the DOD released Directive 5000.29, 
MoucMerestricted all projects to "DOD approved high order 
programming languages" unless cost effectiveness or tecnnical 
practicality was significantly impaired over the system's 
Precawevcle an complying with that directive. "Mcre sbdecifi- 
city was offered by DOD DBirective 5000.31 in November, 19 
meet Gat thas directive svecifically listed the languages 
am@enorizea for use by the DOD. chaastete eae are FORTRAN 
BRaoscC@BOE (DOD), PACPOL (Army), G@MS-2 and SPL/1 (Navy), and 
JOVIAL (Air Force). The issuance of these directives was 
intended onlv aS an interim measure rather than a long term 
solution to the underlying problem of too many embedded 
system computer languages, and as such the directives served 
Only to thwart the development of additional and assumably 
unnecessary new programming Languages.( Given Enews CONSiaer— 
able amount of investment had already taken place in these 
approved languages, there was little immediate need to 


\ 
~\ 


replace them in their present applications. 
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Ceara NEED FOR A SINGLE PROGRAMMING LANGUAGE 
Buc the basic questions still remained: was it feasible 
to develop a universal language, and of the many languages in 
use Doth within and outside the DOD , which if any language 
would best serve as a model to emulate in the development of 
a new language. in answering the first question the DOD 
performed two independent cost benefit analyses, both of 
which concluded that it was appropriate to undertake the 
development of a new universal language which fully met the 
TINMAN requirements. The ultimate benefits possible from such 
an undertaking would most likeiy range in the hundreds of 
Mmebbrons Of dollars in personnel training savings, and 
savings realized through greater use of compilers anc other 
software tools. Toward an answer to the second question, the 
HOLWG was tasked with executing the development of a common 
language, while program management responsibility rested with 
the Defense Advanced Research Projects Agency (DARPA). The 
Criteria imposed on the HOLWG were that it develop a 
language commensurate with state-of-the-art technology and 
design methodologies and that it develop a language of high 
Erougnaeduality so as to be attractive to interests outside 
the defense industry, including (it was hoped) industry, 

universities, foreign vendors and NATO allies. 
/ In January, 1977, -che IRONMAN document was published as a 


requirements definition for the new common language, and this 


14 





document served as the criterion for an international 
competition against the Request For Proposal issued in April 
of that year. Seventeen vendors responded to the RFP, from 
which four were selected to proceed with further design. Ali 
four vendors indicated an intention to use the programming 
language PASCAL as a starting point in their respective 
development efforts. Preliminary design efforts were to be 
measured against the REVISED IRONMAN requirements definition 
document, which was released in July of 1977. Evaluation of 
the preliminary designs was accomplished by distributing the 
preliminary designs amona approximately eight DOD and non-DOD 
evaluation teams from the United States, Europe and the 
United Kingdom. This Phase l evaluation resulted in the 


= 


Peeotieerome OL  =wWwO Of Meco Four vendors for continued 
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Sevyvelepment, and an June of 1978 the final requirements 
document, STEELMAN, was issued. Gn Manwen Ore 3 7/9 etne Lina: 
designs were issued from the two competing vendors, CIIi- 
Honeywell Bull and Intermetrics. 

Again the proposed designs were distributed among 
evaluation teams around the world for comment, and software 
engineers from many disciplines were invited to meet with and 
question the designers to better understand their design 
rationale. The results of these meetings, the comments 


received from the evaluation teams, and an intensive analysis 


ilipe. 





Poeeme adrrrerent DOD interests resulted in the selection of 
CiiI-Honeywell Bull in April of 1979. 

Up to this time no official name had been given the new 
language, though the industry press had unofficialiy dubbed 
the name DOD-1. HOLWG objected to the inclusion of any 
reference to the Department of Defense in naming the new 
language, as such reference could have the effect of 
discouraging acceptance and use of the language in the non- 
military marketplace, and one essential objective of HOLWG 


was to svecifically enhance the vnossibility of acceptance in 


Pi 


that marketplace. | The language name Ada was adopted in tne 
Spemmnqmot 1979 in honor of Agusta Ada Byron, famous in her 
role as the first "computer" vorogrammer. 

In June of 1978 the SANDMAN document was issued, which 
addressed the need to develop an integrated system of 
scftware development and maintenance tools along witn 
development of the language itself. HOLWG reasoned that 
though no special environment would be needed to use Ada, the 
acceptance of the language and the potential benefits 
possible from the development of the Language could be 
Greatly enhanced with the implementation of a standardized 
programming environment. SANDMAN was reviewed as to its 
intent and possible alternatives at a workshop jointly 
sponsored by the Army, Air Force, Navy and University of 


California at Irvine in late June, and this workshop resulted 
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in the preliminary draft statement of Ada environmental 
requirements, PEBBLEMAN, in July, 1978. This document 
described all aspects of the Ada environment, including 
language standards, policy, configuration control, compiler 
validation and scftware and management tools. After wide 
dissemination for comments as to its contents, PEBBLEMAN was 
revised in January, 1979, to reflect the concerns mentioned 


by those submitting comments. 


D. THE ADA PROGRAMMING SUPPORT ENVIRONMENT 

A set of technical requirements for what was designated 
the Ada Program Support Environment (APSE) was published and 
distributed in November, 1979, as Preliminary STONEMAN, along 
with invitations to selected interests to attend an APS#E 
workshop on 27-29 November, i979, in San Diego. At tnis 
BOe<sheo, two Mundred and twenty (220) industrial, research, 
academic and government participants contributed opinions and 
recommendations as to the APSE, and the results of the 
workshop were reflected in the final STONEMAN document which 
was published in February 1980. The STONEMAN requirements 
document delineated the structure and content of necessary 
elements to an embedded Ada system, including the support 
system of the host machine and the run-time system on the 
target macnine. Considerable emphasis in STONEMAN is placed 
on the standardization and coordination of a well defined set 


of tools and uniform interfaces within the APSE to enhance 


iby, 





Ada programming support throughout its life cycle. Such 
uniform conventions, with Ada used to implement the APSE, 
would also enhance such desirble system attributes as 
Peet orerey, lOdULarLty, uniformability and understand- 
apdDility. In addition to the APSE, STONEMAN delineated the 
Kernel Ada Programming Support Environment (KAPSE) to ensure 
standardization of the environment made available to the APSE 
(and therefore ensure APSE portability) in the event more 
than one APSE evolved. STONEMAN aiso defined a Minimal Ada 
Program Support Environment (MAPSE) as a minimum set of 
Functions which an APSE should perform. As defined oy the 
MAPSE, the minimal APSE should de able to create database 
objects, produce new obdiects which are records of analysis of 
other obtects, transform objects from one representation to 
Memon SlODOrt OGOoyect display, parse, link, load and 
execute. 

In addition to development of the Ada language and the 
support environment within which it will reside, the DOD is 
encouraging and funding the development of compilers to 
interface the Ada language with the intended object machines 
On which the language code will be processed. Individual 
efforts are being made by each of the DOD branches so as to 
best match branch (Army, Navy, Air Force) needs with the 
overall development of the Ada language. Perhaps more 


importantly, the DOD wants to encourage the use of Ada for 
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exploratory development and advanced development projects 
even before tne military service and accredited industry 
Production quality compilers are available. As an examvdie, 
the Defense Advanced Research Projects Agency (DARPA) funded 
intermetrics Corporation (the vendor eliminated during the 
Phase 2 language development vendor selection process) to 
SevectOe a test compiler to run on the DEC-20, using the test 
translator it had developed during the Phase 2 language 
Gesign effort. Though the formal intent (and investment) of 
mae DOD is tO develop compilers and other tools whicn wiil 
serve the needs of the developers and maintainers of sottware 
for execution on military computers, there is a recognized, 
though less formal, intent to make available to commercial 
vendors the compiler products developed under the military 
umbrella. This attitude is consistent with one of the 
Pmebal Griteria imposed by the DOD on HOLWG: that of 
Sreating 4 language of High enough guality so as to be 
attractive to commercial and other interests outside the 
Military arena. To this end, the DOD has attempted to 
wiiancemmrtlttary-industrial communication by offering 
Gomeilers, programming tools and compiler test sets upon 
their completed development to commercial vendors, with the 
Proviso that such vendors pay a nominal fee for distribution 
aieeemomit trouble reports to the DOD when trouble with the 


unit 1S recognized. In addition, Ada software developed Dy 
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the DOD (except that software belonging to the core Ada 
development and introduction program) will be available to 
Pemmerciar= venders On an Unlimited basis, unless it is 
determined that procurement by the vendor under limited 
megmes (and DOD's right to redistribute) would result in 
Significant savings to the government. It is reasoned by the 
DOD that encouraging interaction between the military and 
non-military interests involved or potentially involved in 
the Ada language and its surrounding environments and tools, 
will foster the growth and acceptance otf Ada in the non- 


military environment. 


E. EDUCATION IN THE ADA LANGUAGE 

Commensurate with the development of any new programming 
language is the need to address tne education of those who 
Will be responsible for the development and maintenance of 
that new language. This need is brought into even greater 
focus with Ada, since Ada incorporates new concepts and 
facilities as yet unseen in prior programming languages. To 
begin with, Ada is perhaps the first programming language 
where the system goals of modifiability, efficiency, reli- 
ability and understandability were specifically and formally 
recognized as necesSary goals of the language prior to the 
initial design of the language. In support of these goals, 
the software design principles of modularity, abstraction, 


Pieaonmation mMiding, localization, uniformity, completeness 
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and confirmability were also specifically recognized as 
necessary elements to the language prior to its design. 

With these design goals and principles established as a 
See@karop £O tne Ada design effort, certain specific and, in 
most cases, unique design characteristics evolved out of the 
Ada design endeavor. These characteristics include an 
object-oriented design methodology, strong type-checking 
across module boundaries, packages for specifying logically 
Ber,aeed collections of resources, high-level concurrent 
programming facilities, tasking to permit communicating 
sequential processes, and a system framework wherein tne 
language itself and the support environment within which 1¢t 
resides are seen as a "unic"™. 

Meee amen, these goals, oOrinciples and design 
Smeeaceeristics provide a novel training opportunity to 
Dresent a coordinated view of modern programming practices, 
ama bO ch1s anaenene HOLWG established a Subcommittee on 
Maweadtion and Training in Mamemmof L975 = The guiding 
philosophy of the Subcommittee on Education and Training has 
been that Ada represents the cutting edge of anew software 
technology that will inevitably result in a more structured 
working environment for programmers and program managers, and 
an environment that will require the adoption of interface 
conventions which will, to a large part, rely on modules 


developed by others. it Vsommet enough to accomplish local 
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Piamges in eXisting language programs if the proper use of 
Ada's novel features are to be realized, though spinoff 
courses such as "Ada for FORTRAN programmers" or "Ada for 
Pascal programmers” will undoubtedly appear. Rather, Ada 
requires tne programmer to internalize a top-down, modular 
approach to program design that results in orograms whose 
structure is substantially different from existing high level 
Or assembly languase orograms. (The new style of moduiar 
thinking required for the effective design and use cf Ada 
Weegeamowis mMOre Giftficult to teach chan the syntax and 
semantics of the language itself. This is in large part due 
to the fact that many of the issues involved in teaching the 
Ada design methodology are language independent: while thea 
Ada language vorovides linguistic support for the modern 
software technology on which it is based, the underlying 
software methodology and voroblam-solving techniques are 
themselves independent of Ada or any other particular 
language. | This "indevendency”" between language and software 
methodology was not by accident. Rather, it was specifically 
intended by the HOLWG as a means to more easily accomplish 
the possible transition from Ada to whatever future languages 
that might come along. The HOLWG reasoned that thougn 
languages may come and go, a sound and well designed system 
of underlying software methodology and problem solving 


techniques will stand a better chance of survival over time 
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and will provide a standard and foundational basis with which 
to describe the desirable properties of programming ianguages 
in general, as well as a basis from which future programming 
languages in particular can be developed. 

The thresnold, then, to be overcome in the training of 
programmers and program managers in the Ada language is 
substantially higher than that of previous languages, as Ada 
demands an understanding of 1ts underlying philosophy and 
mepPbeded PrrOr tO the understanding of its syntax. This is 
eae wen Macroscopic” approach to language design, since it 
forces the programmers and program managers to maintain a 
perspective on the language which sees the language as mereiy 


peewee le uwith whiten to enforce the far more importa 
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Shilssophy behind the language and tne goals and drinciples 
supporting the Language. | This approach has the added benefit 
SuetOrcing the designers and users of Ada to consider the 
effects of uSing Ada aS a Programming language for any 
SPecitic Oroject over the project's entire life cycle rather 
than in piecemeal fashion. 

To meet the Ada training challenge, the Subcommittee on 
Education and Training is coordinating various individual and 
coordinated training programs among the components of the DOD 
Medeeinadaition, is endorsing education and training 


endeavors within the commercial and academic sectors pbotn at 


home and abroad. 
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F. ADA AS A “SOLUTION" TO THE SOFTWARE CRISIS 

| There is little doubt that the development of Ada nas 
caused considerable commotion in the computer software arena. 
Some would argue that the horse is finally once again ahead 
of the cart in software development in that with Ada there 
seems to have o2en no #exvdense sdared in laying a 
comprehensive and foundational design strategy and framework 
prior to designing the language syntax itself. Cada apoears 
to represent for the first time an attempt to psuild a 
fundamentally new software design philosophy rather than just 
anotner "new" Dut, in fact, patchwork software Language. | The 
software crisis is with us and will remain so for many years 
fo come, but the injection of the Ada language into that 
Crisis will at least slow what is now an uncontrollable rate 
9£ growth of that crisis. This, of course, assumes that Soth 


DOD and non-DOD interests continue with their efforts on what 


appears to be the right path. 
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If. SOFTWARE ENGINEERING CONCEPTS UTILIZED IN THE 
DEVELOPMENT OF ADA See 

The fundamental reason for the existence of the "software 
crisis" is due to the unmanageable complexity of software 
systems in general. As tools for software development 
improve anc as software system design experience increases, 
Silcmobellation is clearly becoming more difficult to deal 
with as newer and greater problems arise. A solution for 
Beaucing the complexity of software systems is attainable 
through close adherence to the goals and methodologies of 
software engineering suppdorted by a high order language that 
promotes and enforces these principles. 

Software engineering is modeled on the techniques, 
methods and controls associated with hardware development. 
Although fundamental differences do exist between hardware 
and software, the concepts associated with planning, develop- 
ment, review, and management control are Similar for both 
system elements. The key objectives of software engineering 
are (1) a well defined methodology that addresses a software 
life cycle of planning, development and maintenance; (2) an 
established set of software components that documents each 
step in the life cycle and shows traceability from step to 


step; and (3) a set of predictable milestones that can be 
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faa tewed at regular intervals throughout the software life 
eevcile {Ret. 3s,.p. 15). 

The purpose of this chapter is to delineate tne goals of 
software engineering and discuss the associated principles 
that enable software system designers to attain them 
Deer, 4). Ths chapter will also discuss software 
development techniques and tools that utilize these software 
engineering Drinciples in tne design of scftware systems. 

A. THE GOALS OF SOFTWARE ENGINEERING 

Mhe most Fundamental goal in the design of software is oa 
ensure that the resultant product satisfies tne designated 
requirements. Unfortunately, there often arises a misinter- 
pretation of the user's stated requirements by the system 
Miptemencters. AS a result of this misunderstanding, cnanges 
in requirements during the life cycle of a software system is 
Lnevitable. 

The acceptance of the inevitability of changes in 
requirements during software development has resulted in the 
establishment of a set of goals that overcome the effects of 
such change. Four properties that are sufficiently general 
to be accepted as goals for the entire discipline of software 
engineering are modifiability, efficiency, reliability, and 


understandability. 
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1. Modifiability 

Boecmdeal Obemoditiabidity oie —the most difficult goal 
tO master and to measure. Modifiability implies controlled 
change, in wnich some parts or aspects remain the same while 
mumers are altered, all in such a way that a desired new 
result is obtained. Modification during software development 
may occur as a result of a change in the system requirements 
Or in response to tne Correction of an error made earlier 
during the development phase of the system. 

Mee —neagpiGacation of a system must take into 
SPemerCebraeton EXS Staintenance OF structural integrity. TIE 
mrs COmsiaderation iS ignored during modification, the 
software will become segmented, resulting in a potential loss 
Bre togucal flow. This will invariably lead to tne original 
Gesign becoming vague and unintelligible, making follow-on 
modification to the system very difficult. The kev to system 
modifiability is that it should promote the ability to change 
the software without enlarging the complexity of the system. 

Zs See orency 

In well engineered systems there is a natural 
tendency to use critical resources efficiently [Ref. 3: 
D. coe]. These resources are classified into two basic 
groups--time and space resources. Time resources are 
generally concerned with process execution in a predetermined 


timeframe; hence, they tend to be hardware dependent. 
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However, selection of the proper software algorithms will 
obviously enhance the time of execution. Space resources are 
concerned with the physical side of the execution process. 
Hmoedded systems are often required to consider both 
Sassi f£ications to promote efficiency. If the embedded 
system is concerned with real events, time resource 
efficiency becomes paramount. If the embedded system is 
constrained by the physical size of the existing hardware, 
then space resources become the overriding concern. Most 


often, the efficient use of the two classifications at the 


(fa 


ame time is not attainable and a tradeoff must occur. 

In order for efficiency to be attained in a system, 
lt must be considered throughout the entire system 
Mevelopment and not gust in the early phases as is most 
common. Insights reflecting a more unified understanding of 


a prodDlem have far more impact on efficiency than any amount 


It 


Sam O1L ew2dgGling” within a faulty structure. 
3. Reliability 

As more and more computer systems are being developed 
to operate for long veriods of time with minimum overator 
interference, reliability of the system is taking on greater 
importance as the price of system failure reaches 
Bneeceepeaqmer lity. Reliability must both prevent failure in 


conception, design, and construction, as well as recover from 


failure in operation or performance. 
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ASP witn efficiency, reliability must be a concern 
throughout the entire software development program. Most 
Mearemese tabi lity is considered too late, or not at all, in 
most software development efforts. Reliability can only be 
PUrresim £rOom Ehe start; it cannot be added on at the end. 
Hence, reliability has a pervasive and crucial effect on 
software engineering practices. A well engineered, reliable 
computer system must fail gracefully with little or no effect 
fo the system overall. 

4. Understandability 

Understandability 1s the key to the proper management 
of the complexities inherent to software systems. Under- 
aeoNdaomliry 1s not exclusively a property of legibility. 
Mmememet™re conceptual structure is involved. 
Understandapility bridges the true system with the verceived 
system. Although understandability 1S a prerequisite to 
BePrapiieey and modifiability, it is also important as a goal 
in itself because it draws attention to the complexity of the 
System. The only way to achieve understandability is to 
impose clearly notated structure and organization on the 
system. 

System understandability is further enhanced from the 
impact on the system from various levels in the structure. 
From the lower levels, proper coding styles lend themseives 


to understandability. At the higher levels, the ability to 
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expedite the segregation of various algorithms and ada 


ct 
fv 


structures aid in understandability attainment. 


B. THE PRINCIPLES OF SOFTWARE ENGINEERING 
[The software engineering goals are clearly applicaple to 
most if not all software systems. These goals, however, are 
not attainable simply through utilization of any software 
development methodology. In order to achieve these goals, 
the software development approach must be hignly structured, 
well disciplined and closely adhere to a basic set of soft- 
ware engineering principles that supodort these geals. The 
Peameve1es Of SOTtware engineering include abstractions, 
ironomatren aiding, Mogdularity, Localization, uniformity, 
completeness, and confirmabilitv. Proper utilization of 
these software engineering principles can result in the 
development of a software system that is modifiable, effi- 
cient, reliable, and understandable. » 
1. Abstraction 
As stated previously, the inability to manage the 
complexity of software systems is the primary cause of the 
"software crisis." Abstraction lends itself to managing the 
complexity. Abstraction exists in varying degrees throughout 
all levels of the systems hierarchial structures. Each level 
of abstraction is built from lower levels which in turn were 
Duilt from even lower levels in the hierarchy. In developing 


SOmeware systems, the level of abstraction that satisfies the 
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Stated requirements is utilized. The essence of abstraction 
1s to extract essential properties while omitting unessential 
details. SicmmeeVetnom= of Nagstractwon EOrmed “Eenrough 
hierarchial decomposition, display an abstract view of the 
lower levels purely in the sense that details are subor- 
dinated to the Lower ievels. The principle of abstraction 
ensures that a given level in a hierarchial decomposition is 
understandable as a unit, without requiring either knowledge 
of lower levels of detail or necessarily how it participates 
in the software system as viewed from a higher level. 
Z. Information Hiding 
PimouNatwenmeniding enforces the abstraction prin- 
ciple. Where aostraction was concerned with the extraction 
of essential details cf a given level, the purpose of infor- 
mation hiding is to make inaccessible certain details that 
Should not affect other parts of a system. Abstraction helps 
ES identity details that should be hidden, while hiding is 
concerned with defining and enforcing access constraints. 
Bicmapplicaeien of the information hiding "principle 
merPcon#uNnction with the abstraction principle promote goal 
achievement. These two principles, besides encouraging 
system efficiency, assist in the maintainability and under- 
sStandability of a software system through reduction in the 


amount of specific details a system programmer would be 


meq@ectead to Know at any Particular level. System 
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reliability 1s also elevated through the application of these 
two principles, for at each level only certain predefined 
Operations are permitted to occur preventing any inadvertent 
Seeration from taking place that could violate tne logical 
Seremcture of that level. 
3. Modularity 

It has been stated that modularity is the single 
mere route of software that allows a program ts be 
intellectually manageable [Ref. 5]. Modularity is concerned 
witn the dividing of a program into subvrograms (modules) 
farrer can be compiled separately. Moduiarweey visieds oa 
Weerarenhial Structtire, for when decomposition of the software 
system occurs levels of program modules are created. 

In utilizing a tov down approach in software design, 
a decomoosition of each successive ievel into distinct 
functional modules will occur. Most often, higher level 
modules are related to high level abstractions, and therefore 
are generally machine independent. In addition, a nigher 
level module wiil specify what action is to be taken, while 
the lower level modules define how tnat action is to be 
Gar rredwout. Lower level modules are generally machine 
dependent. If a bottom-up approach to software design is 
initiated instead, decomposition of the system begins at the 
bottom of the hierarchy resulting in the creation of nighly 


complex modules at the top of the system. 
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The key to the enhancement of system reliability 
through the use of modularity is to ensure that a well 
defined interface exists between each module. A well defined 
interface 1S an explicit set of assumptions one orogram 
module makes about another. These interfaces are the "connec- 


% 


tions” between modules. A measure of the strength of these 
interconnections among modules is known as coupling. Looselv 
coupled modules are most preferred for they result in greater 
modular independence. Cohesion is another modular measurement 
Mmrpen decines aoOw tigntly bound or related its internal 
PeeMenes are tO One another within the module proper 
Sec ouemotreng cohesion within individual modules is most 
Gesirable for it implies that the components of a Darticular 
module are functionally and logically devendent. 
4. Localization 

The principle of localization assists in developing 
program modules which demonstrate loose coupling and strong 
Seteastone Che principle of localization is concerned with 
physical proximity where related elements are drougnt toge- 
ther all in one module resulting in a reduction in resource 
redundancy. Through the use of the localization principle, 
logically related items are collected into one physical 
module, forming a module that exhibits strong cohesion. The 
localization principle also implies modular independence, 


resulting in a much desired loosely coupled system. 


33 





The principles of localization and modularity lend 
themselves greatly to the attainment of the goals of software 
engineering. If a software system is developed through the 
implementation of these orincivies, then the understand- 
ability of any particular module should be possible 
independent of the other modules in the system. Subse- 
quently, since these principles tend to localize design 
decisions into pre-defined modules, the effects of modifica- 
tion to the system can be minimized to a smaller more 
manageable collection of modules. Pie’ joa Of =syvoaram 
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mpeaoeeeley oS enhanced due to tne fact that the prooer use 
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o£ these principles will result ina redu 
Sieemocular interfaces. 
Seon vr Orms CY 

Eifemuimerormaty Srinciple is directly related to the 
software engineering goal of understandability. Uniformity 
1s concerned with intermodule notational consistency in areas 
wlemewas Naming conventions, code structure, interface 
Pesermectons, evc. Unizormity is achieved through the use of 
proper coding techniques, where application of a consistent 
control structure and calling sequence for operation 1s 


utilized and where the depiction of logically related items 


are identical at any particular level. 
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6. Completeness 

The purpose of this principle is to ensure tnrat all 
essential elements have been included in the software system 
development. Completeness is achieved through proper 
iterative design procedures through the system development 
phases. Completeness in combination with the abstraction 
DOrinciple, results in the development of necessary and 
sufficient modules supporting the goal of reliability. 
Completeness also enhances the efficiency goal, because it 
becomes possidle to adjust a lower level module without 
affecting modules in tne higher levels. 

oy @Gentiemability 

The princivdle of confirmability is concerned witn 
achieving stated goals contained in the software system 
requirements and specifications. — Tt is, therefore, Daramount 
co ensure that system requirements are accurate and that 
system specifications are testable. Confirmability implies 
that decomposition of the software:-system must occur so that 
it can be readily tested resulting in a system that is 
modifiable. This principle is most commonly realized through 
the use of informal software system reviews such as 


Segmecurceduwalkthroughs [Refs 3; p. 141). 
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C= SOFTWARES DEVELOPMENT DESIGN METHODOLOGIES 

software engineering principles will, when correctly 
applied, achieve software engineering goals. However, these 
beenciples cannot be implemented in a casual, hit or miss 
fashion. As software systems are becoming more and more 
modularized, a uniform system decomposition standard must be 
adhered to. 

There are generally four recognized design methodologies 
that exhibit a uniform standard for system decomposition. 
These are top down structured design, data structured design, 
Parnas decomposition criterion and object oriented design. 

1. Top Down Structured Design 

The too down structured design approach is based upon 
the hierarchial organization of modules. Wai Sued oDroacn 
Suggests the decomposition of a system 15 achieved by maxing 
each step in the process a module [Ref. 6: p. 106]. This 
approach begins with the top level module designed in terms 
of the modules of the next lower level. In essence, a deter- 
mMination is made as to what tyve of modules will be required 
on the next lower level and how they should be connected to 
EOLmeehwemtop level module. As this is hapoening, no conside- 
ration is given about the detailed construction of the second 
lower level modules until the top level module has been 


Satisfied. This process continues until all modules at all 
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Bevews are fOrmulated in terms of the modules below them. 
Maes process "results in program modules that are highly 
functional and well defined. The higher level modules contain 
the highest levels of abstraction, while the lower level 
modules contain the primitives of the system which implement 
operation in response to higher level actions. 
4. Data Structure Design 

The data structure design methodology converts a 
Meeresentacion of data structure into a representation of 
software. Utilizing this approach, the data structures must 
first be defined, and tnen the program elements ara struc- 
tured based upon the data structure itself. This then is an 
attempt to clearly and precisely explain the implementation 
of the objects in the solution space and then allow their 
Sole tewew structure to become visible to the essential 
functional elements that furnish the operations on tne 
objects. In general, data structure design defines a set of 
"mapping" procedures that use information (data) structure as 
peecuadem (Ref. 3: p. 141). This approach recognizes the 
necessity for the design of the program to reflect the 
Serueturesot the problem. 

3. Parnas Decomposition Criterion 

The Parnas decomposition criterion methodology is 

based upon the idea that as a system is decomposed, each 


module in the system hides a design decision from the other 
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modules. This approach is implemented through an initial 
Pentre lcation of difficult design decisions or design 
decisions that are Jikely to change over time. Each program 
module is then designed to hide such a decision from the 
Semers. This results in the capture of design structures in 
the software at the level at which the design decision is 
made. If modification of the software system should become 
necessary, ability to minimize the effects of the modifica- 
tion should be readily available. This emer e rT On wats > 


Supports the idea tnat to achieve an efficient svstem 
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zmOlementation, the assumption that a module is one or more 
subroutines must de abandoned in favor of allowing sub- 
routines and programs to be assembled collections of code 
meacmheevar1ousS modules [Ref. 7: p. 225}. 
4. Object Oriented Design 

Object oriented design is a relatively new approach 
to software design that has developed as a result of the 
[ens Ofmyarious people im the discipline [Ref. 8: p. 38]. 
This methodology allows the mapping of solutions directly to 
the designer's view of the problem. The object oriented 
design approach first clearly and concisely defines the 
problem. An informal strategy is then developed to provide 
Bee direction toward the solution of the problen. 


Paar y, —the strategy is formalized. During this step, 


identification of the abstract objects at given levels in the 
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System takes place. The appropriate operations on these 
objects are then defined. Interfaces are established and 
Operations are implemented. The last step is to develop a 
moduie that hides the implementation. 

This methodology provides a meaningful strategy for 
decomposing a system into modules, where design decisions are 
localized to complement the real world view. This approach 
also provides a consistent notation for cnoosing the objects 
mea Operations that form the design. The object oriented 
design approach orovides an enforceable structure which 


Sono sass Some of the complexities involved in software 


system design. 
D. THE USE OF PROGRAMMING LANGUAGES AS SOFTWARE DEVELOPMENT 
TOOLS 
Sortware system design methodologies are not sufficiently 
Sapable of producing computer solutions on their own. These 
approaches require the assistance of software tools, 
particularly through the use of programming languages, to 
express and execute design. In order to discuss the evolu- 
tion of programming languages into efficient software system 
design tools, a language generation outline of the most 
popular programming languages and some language features are 


Provided [Ref. 9]: 
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First Generation Languages (1954-1958) 


FORTRAN I 
ALGOL 538 
Flowmatic 
IPL V 


Second Generation Languages (1959-1961) 


FORTRAN II subroutines, separate compilation 
ALGOL 60 block structure, data types 

COBOL data description, file nandling 
LISP list processing, pointers 


Third Generation Languages (1962-1970) 


eviyeal FORTRAN + ALGOL + COBOL 

ALGOL 68 rigorous successor to ALGOL 60 
Pascal Simple successor to ALGOL 60 
SIMULA classes, data abstraction 


The Generation Gap (1970-1980) 


Many different languages, but none endured. 


As can be readily seen from the outline above, the more 
commonly utiiized nigh order languages, FORTRAN and COBOL, 
Came into existence in the early history of computer science, 
Beiore the advent of the “software crisis." Accordingly, 
these high order languages were not founded on modern 
software design principles and, as a result, these languages 
nad to be modified by use of preprocessors (S-FORTRAN) and 
extensions (FORTRAN-77) to bring them into compliance with 
current software design metnodologies. Needless to say, 
these languages were formulated prior to the recognition and 
acceptance of the fact that large, modern software systems 


are far too complex to efficiently manage. 
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These high order languages continue to fulfill needs cof 
their individual problem domains; however, since their 
creation, the large embedded computer systems domain has 
arrived. None of these high order languages was designed to 
cope with the inherent complexity associated with embedded 
systems. 

A discussion of the basic structure of these high order 
languages will demonstrate some of their intensive oroblems 
[Ref. 8: p. 34]. FORTRAN and COBOL were both designed with 
flat structures, Drimarily made uv of global data and one 
level ct subprograms. The innerent danger associated with 
Mibcmeype Of Structure is that an error introduced in any 
segment of a Drogram can result in catastrophic ripple effect 
across the entire system due to the global data structure. 
Modifications to large systems utilizing these high order 
languages generally result in the disintegration of the ori- 
Ginal software system design structure. Maintenance on 
orograms written in these languages often oroduces large 
amounts of cross coupling among program units, resulting ina 
lessening of system reliability and solution clarity. 

Most of the second and third generation languages became 
capable of vroviding a larger nested structure for more 
complex algorithms. However, tnere was little or no 
improvement in the ability for describing data structures. 


The basic structure of these languages was very similar to 
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that of the first generation languages with the major 
mae remce o61ng the existence of subprograms within 
Subprograms. Unfortunately, these languages were plagued 
with tne same problems inherent to the first generation. 
some languages in this generation such as SIMULA, did 
demonstrate the ability to provide greater data structuring. 
MOwevyer, tnoese languages Failed to gain any sizeable 
Speaqibility. 

Assembly languages are presently the most commonly used 
languages for emoedded systems. Assembly languages exhibit 
Pemtnngenrent structure. AS a result, assemoiv Languages 
Mrovilee Great Elexioility in develooing systemB and assembly 
languages can be written in structured assembly code. 
However, once a svstem becomes fairly large, the mere nature 
or the language tends to confuse the organization. 

The evaluation of fourth generation languages, such as 
Ada, are already demonstrating tremendous potential in the 
alleviation of the problems associated with the description 
of data structures. These languages are able to control 
system complexity through ohysically concealing unessential 
details at each system level. Their basic structure supports 
the localizing of design decisions, and maintains the 


Structure of the original design as modifications are made. 
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III. SURVEY OF CURRENTLY DEVELOPING PROGRAM DESIGN LANGUAGES 


me ee ee em ee eee gee SS SE —— 


During the past several Venee stinclasteey has seen an 
explosion in the cost of software production counled with a 
decline in the quality and reliability of the results. A 
realization that structured programming, top down design, and 
other cnanges in techniques can nelp has alerted the field to 
the importance of applying advanced design and programming 
Mmemmrods tOpsoftware production [Ref. 1: p. 5}. One of Ene 
mOSt Dromising software system design tcols to amerge fErom 
the appreciation of this problem has been the development of 
the program design language (PDL) concept. This chapter will 
define the orogram design language toncept through a 
MesGUuSsion Of its functions and attributes, and conclude witn 
a description of currently developing PDLs as outlined in 


Reference 10. 


A. PROGRAM DESIGN LANGUAGE CONCEPTS 

The term Drogram design language is used synonymously 
with other recognized software engineering terminologies such 
as pseudocode, structured English, and metacode. However, 
for purposes of discussion, the acronym PDL will be utilized 
exclusively throughout this chapter and the remainder of the 
thesis. Conceptually, a PDL is a very high order programming 


language designed to relate the logic of a program module in 
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an understandable and readable format at any given level of 
detail. PDLS were originally designed for a top down approach 


to software system design development. It is considered a 


i) 


"Didgin”" language in that it uses the vocabulary of one 
language (1i.e., English) and the overall syntax of another 
(1.e€., a Structured programming language) [Ref. 3: p. 253]. 

On the surface, PDLs appear to be very similar to the 
existing third generation programming languages develoved in 
the 1960's. However, a major dissimilarity exists in tne 
Fact that PDLs utilize English as a narrative text enbedded 
expressiv inside PDL statements. PDLs combine tais narrative 
meecewitad a f£Ormal procedural format that forces upon its 
userS a programming language-like syntax which enables 
automated tools to assist in the development of detaile 
design. Presently, the combination of tne narrative text 
with the formal procedures makes compilation of PDLs 
impossible. However, this set of automated tools known as 
PDL orocessors, maxe it vossible to design operational 
indices, format text, oroduce cross reference tables and 
nesting maps, check validity of the syntax, and perform 
several other functions. 

iiewrmpute cto the PDL processor is comprised of control 
information and designs for procedures Known as segments. 
These segments are utilized to describe the algoritnms used 


in performing the mandatory steps contained in a program 
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module. They make up tne interface snecifications between 
moaguies and are used to define the functions performed by a 
given module. Since PDLs utilize module structure in theic 
eremitectural design, each segment contains only a small 
portion of the overall system logic found within the module. 
iars Use Of PDL segments results in the creation of 
algorithms that are more precise, easily understood, and more 
Bepidsy modified supporting tha statanerit that, "The o1urp5se 
of a design is to communicate the designer's idea to other 
Beeombe--not tO a computer” [Ref. ll: p. 271). 

The outDut from the PDL orocessor is in the form of a 
working design document. This outvout has been recognized as 
an extremely effective replacement fFor conventional 
flowcnarts. There are several apparent reasons why PDLs are 
Seeeecttye in accomplishing this: 


1. They are machine-processadle, uSing the text editing 


facilities available in the software develooment 
environment. 


2. They can be easily Bede SOm tak a Grow Jor 
designers can easily review the PDL of a given designer 
to determine the quality of tne design (structured walk 
Earougn). 

3. They are read in atop down manner and provide a 
more accurate reflection of the program structure than 
do flowcharts at a larger stage in software development 

Through the example of simple sorting algorithm, Figures 
3-1, 3-2, and 3-3 [Ref. 19] clearly demonstrate the 


overwhelming clarity inherent in PDL output documentation 


45 





mecemwcnat Of Conventional flowchart or a third generation 


programming language (PL/I) presentation. 


SORT (TABLE, SIZE OF TABLE) 
fio 2h sOr TABLE > tL 
DO UNTIL NO ITEMS WERE INTERCHANGED 


DO FOR EACH PAIR OF ITEMS IN TABLE (l=2, 2-3, 


BD; A “aol. 
ia Se pe ee) 


te i Rol sl PeMaOr PATR > SnCOND Theor 
PAIR 


INTERCHANGE THE TWO ITEMS 
iN IO IES. 
ENDDO 
ENDDO 


ENDIF 


Figure 3-l. PDL Design of Simple Sorting Algorithm 
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SORE : 
PROCEDURE (TABLE): 
DECLARE TABLE (*) FIXED BIN: 
DECLARE INTERCHANGED BIT (1): 
Dee Tome FIXED BIN: 
if Dawe (TASLE, Ll) > 1 THEN 


Bor: 
INTERCHANGED = '1'B; 
DO WHILE (INTERCHANGED) ; 
INTERCHANGED = 'O'B; 
DO I = LBOUND (TABLE, 1) TO 
HBOUND (TABLE, 1) -l; 
IF TABLE (I) > TABLES (I+1) THEN 
DO: 
INTERCHANGED = '1'B; 
TEMP = TABLE (I); 
TABLE (I) = TABLE (I+tl); 
TABLE (I+1) = TEMP; 
END; 
END; 
pe 
END 3 
mp SORT; 


Figure 3-3. PL/I Procedure for Sorting Algorithm 


These figures lend themselves to demonstrating one of the 
most important attributes of PDLs; the ability to quickly 
Pevwelroo a COArSS Droftile of a Srodiem solution that is both 
r2eadadle and understandable by all. This aids in design 


modification since individuals at all levels in tne svste: 


J 


design development phases are capable of quickly and 
BesutLatery identifying errors and potential problems and 
ensuring correctness. Other characteristics that PDLs 
Should comply with are: 

Ll. A fixed syntax of KEYWORDS that provide for all 


Sweaicturea constructs, data declarations, and 
modularity characteristics. 
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2. A free syntax of a natural language tnat describes 
processing features. 


4 


S-eewaca cdeciliaration Eacilities that should include bot 
Simple (scalar and array) and complex {linked list or 
hierarchical) data structures. 


4. Subprogram definition and calling techniques that 
Support various modes of interface description. 


5. A PDL should be programming-language-independent. A 
design described with a PDL should be translatable to 
assembly language, FORTRAN or PASCAL [Ref. 3: Dd. 253]. 

PDLs in themselves are not a panacea for tne ills that 
afrect software system design. However, if the PDL conceodt 
is utilized effectivelv, the goals and principles of software 
engineering can oe achieved quite successfully. 

Another software design concept which is gaining greater 
meeceopecance tEhroughout the discipline is tnat of a Systei 
Design Language (SDL). Whereas PDLs provide a detailed 
description of a vrogram module, SDLS can ve viewed as a 
module interface language for a format architectural 
Gescription of a system. The SDL concept is a logical 
Outgrowth of the PDL concept. An SDL ideally will identify 
those system components neeadeduies be constructed and what 
interfaces each component provides and requires. A PDL, on 
tne other hand, identifies now each component is t9 be 
Gonseructed. BOGEN E, enesemcoOncepts Eorm the “blueprint" 
For actual software system implementation. Although these 


concepts are closely related, a formal discussion of System 


Design Languages is beyond the scope of this thesis. 
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Be SURVEY OF CONTEMPORARY PDLS 


Several software vendors have been developing EDLs to 
assist them in the creation of software systems. Eas 
research and development effort has been stimulated to a 
large extent by the DOD initiative concerning the davelopment 
of Ada for use with embedded computer systems. Many of the 
PDLs now being develoved are in fact Ada-vased design 
methodologies. 

ono r wEMe —ToSt DOreomising PDLsS currently under 


Hiieeee= aac oe so aoe Shee oho mec BM 
femoroomen: 2t2 being built by Harris BanGelat Oem ea, ot 


and Norden Systems. Each of these PDLs has a distinct syntax 


Shecescacn  SUDDOrTES a dimunmitive variation jin design 


methodology. A brief description of each PDL follows. 
Additionaily, a macrix demonscrating the ida Language 
Meaqelines supeorted by each vendor's PDL is included as 
Apvendix C. 
ear. s PDL 

The PDL developed by Harris exceeds tne confines of 
conventional PDLs by including guidelines for the software 
development process. Harris redefines the term PDL to mean 
"Process Descrivtion Language' to reflect the extended 
eolgmeveadeaon for the language. ins Oleic: Lizes ewe 


constructs for clarity enhancement, a ‘'call' keyword prior to 






subpregram calls and an ‘engage' keyword orior to task calls. 
The Harris PDL also embodies six keywords for file 
Prout /output. These are ‘open', ‘write', ‘read', ‘'close', 
‘delete’, and ‘'create'. Harris also permits the usage of 
Structured English statements in the form: VERB NOUN/OBJECT 
(OPTIONAL MODIFIERS). 

For the program develooment, the Harris POL utilizes 
Four approaches. The First approach is top-down partitioning 
wnich is used to break down the system into layers of 
mutually exclusive subsystems, which, when taken as a whole, 
tctally encompass the original design. The second approach 
is Known as orogressive elaboration. This approach is used 
Pi cCoOnmumetton with the top-down partitioning apdDroach so 
that as the system is being broken down laver by laver into 
modules, detail is progressively added to the data and 
Process structures. Hos ZOmedleCOompilation iS ,Ene mexc 
BpDroOgeh. PnAwetemn Zomtalmwecomezlation,s» as top-down 
Sweceetoning OCCUumS, 2aGm layer tan 52 computed to test for 
Seonscisceme ama complete partitioning as well as correct 
syntax. Vertical verification is the fourth aporoach. This 
method is used to insure tnat nothing nas been left out or 
added in succeeding layers of partitioning. The Harris PDL 


effectively lends itself to the achievement and support of 


the software engineering goals and princiovdles. 





2. TRW PDL 

The TRW Corporation is developing a PDL based 
Drimarily on the Ada programming languages for use by the 
Devartment of Defense. Since the issue of the utilization of 
Ada as a PDL will be fully discussed in a subsequent chavdter, 
the description of tne TRW PDL will be of limited scope. 

The TRW PDL supports tne basic constructs of the Ada 
programming language, i.¢., packages, compilation units, 
tasking, generics, typing of data and data hiding. However, 
some Ada language features are not supported by this PDL. 
Sewers StAasements sucn as null, procedure tall, aoort, and 
assignment lack proper supports. 

Moe Mest SPGmiswean: Esature of the TRW PDL te that 
it permits the insertion of narrative text into statements in 
lieu of Ada comments. Although this is viewed by Ada PDL 
BasMPoc®=rs as a potential Broolam, it indicates that TRW is 
akcteamoting to develop a PDL with a certain degree of 
programming language selection flexipility. 

5. WEMPPDL 

IBM has deen working on program design languages for 
several years. The methodology for the development of its 
PDL is focused on the following design language requirements: 


[_——EImaGOrLced recordimg of both interfaces and behavior 
Specifications as part of the design of the software. 


Za POST t1Om Of Structure while allowing for free-form 
expression of specification ideas. 
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Same mata aeclaration fPacilveres “26 alow Gefrinition o£ 
both individual scalar values and data groups. 


4. Definition of user defined data types. 


Sever Imition and use of procedure and functions to 
Orovide modularity. 


6. Concurrent assignment notations that one can express 
ina design the situation of several inputs producing 
several outputs in an unspecified sequence. 

7. Encapsulation and information hiding. 

8. Formal commentary with specified format and scope. 

9, Support for stepwise refinement of the design. 

Stierentiy utilized third generation programming 
Mamgmases DOSSess many, Sut not als, of the attributes Listed 
apove. The growing popularity in utilizing Ada as a base for 
a design language is due to the fact that these forameantioned 
attributes are directly embodied in the Ada language. IBM is 
developing, 1n vDarallel witn its generic PDL, an Ada PDL 
which encompasses these attributes with other Ada concepts. 

4. Norden PDL 

Norden Systems has also bdDeen developing PDLs for some 
eee rneir PDL iS a non-compilable PDL similar to tne 
Caine, Farber, and Gordon PDL discussed in Reference ll. 
This PDL 1 backs the more vowerful language features such as 
strong typing, loop exits, and tasking and, as a result, 
Norden has opted to develop an Ada oriented PDL. This new 
PDL, NPDL/Ada, utilizes an Ada syntax, embodies the major Ada 


language features yet retains the expressive freedom of the 
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Englisn language text while embedded in the more rigid Ada 
CoOncerol structures. 

The software vendors who are creating PDLsS, are 
guickly recognizing the inherent value of utilizing the Ada 
programming language as a Dasis for the development of PDLs. 
The concepts and features that make the Ada programming 
language so conducive to utilization as a PDL will be 


discussed in the next chapter. 
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IV. EXAMINATION OF ADA CONCEPTS 


A SERIE 


A. BACKGROUND 

The explosive growth in the cost of developing and main- 
taining complex software systems has fostered the advancement 
of a large number of techniques and theories developed in the 
area of software design and development. These theories and 
tecnniques inciude structured programming, top-down design 
and implementation, structured analysis and desisgn, modulari- 


ye cantral 


‘ome = =» = * aioe 


4 


@aeion, and programming teams and walkthroughs. 
aim of these theories and techniques has deen to attempt 
intellectual control of a software system design via systema- 
Sucwa@ocemoosition and adstraction of the software oroblem 
into component modules and subsequent composition of tnose 
mocmlea imaemthe system [{Ref. ll: o. 220}. Only with an 
inteliectual control and working understanding of large, 
complex software systems can the development and maintenance 
costs of those systems de kept in cneck. 

Recognizing that development ofene Ada language anor acs 
MoOLwainmiaue OpDOrtunity to discard the inefEiciencies of 
Older generation languages while creating an entirely new 
method with which to allow intellectual control over complex 
system Peer earene HOLWG established thrae guiding 
Principles or goals early in the Ada development process. 


These goals are: 
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~ recognition of the importance of program reliability and 
maintainability; 


pee o@cGerResOr DzOgramming as a human activity; and 
~- efficiency. 

The finalized STEELMAN document reflected the 
desirability of these three goals by mandating that the final 
Ada language support the following language features 
Peete o+ 2p. 1S): 

- structured constructs; 

ereeserong EVping; 

Segelaei Ve and absolute precision specification; 
~ information hiding and data abstraction; 

- concurrent processing; 

eee] oc on 2andling; 

~- generic definition; and 


- machine depvendent facilities. 


B. LANGUAGE OVERVIEW 

(oe the three goals envisioned by-the—-HOLWG, the first and 
most important was considered to be that of reliability and 
Maintainability, as together these make up tne largest cost 
Geedcetmea SOfiware system's Life cycle. In an attempt to 
MaXimize reliability and maintainability of Ada software 
systems, Ada was designed to be, and is, a design ianguage. 
As such, it focuses primary attention upon tne interconnec- 


tion of the interface characteristics of the components 





within a system rather than upon the components themselves. 
Somewhat lixe the manner in which a blueprint describes oe 
way things fit together without extensive detail as to wnat 
those "things" are, Ada emphasizes the interconnection 
between module eer © tee over the structure within tnose 
modules. Further, it is the interface characteristics which 
actually define the components which are used in the design 
because the interface characteristics are all that the user 
of the component needs to use the component and all that the 
designer needs to design the component. ‘This apprtoacnmrs 
Merguege G2sign svecificallvy suprorts modularization, intor- 
mation hiding and abstraction as tha user need not see the 
sontents (now) within gach module, but rather he need only 
see the interface (what) and interconnection of modules. 
mis approach is also multi-tiered, as within each module 
there exists a system of interconnectivity between interfaces 
of lower level modules, down to the level where further 
decomposition becomes inapovropriate. An Ada software system, 
then, can be viewed in its entirety as a single module witn 
tne comdonents of that module being the interconnections of 
interfaces of lower level modules, and so on down to the 


lowest level modules in the system. 


C. OBJECT ORIENTED DESIGN 
A methodology with which to approach the design of a 


software system where that system is intended to solve real 
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world problems has been advanced by Grady Booch [Ref. 3: 
eaes.0 ). His methodology, called object-oriented design, 
begins with the recognition that there is a problem space 
wherein real world problems are begging of a solution, and 
there is a solution space wherein computer software and 
hardware combine to accept real world problems, process those 
problems toward solution, and inject those solutions back 
into the real world. In any programming language the 
programmer translates (abstracts) real world problems from 
maemmDrodlem space (real world) to tne solution sdace 
(software). The software/nardware svstem operates on these 
aostractions toward a solution by way of an adstract probiem- 
solving technique (softwar2 algorithms), and the solution is 
Enen Converted back to the real world by way of computer 
Output. The primary problem with computer languages pDrior to 
Ada is that a considerable distance exists between the 
problem space and the solution space, resulting in tne need 
Pome <OrmcmeCOnSGiaerable effort in oofrn converting 
laopstraG@eing) to @nd from the solution space and operating 
efficiently within the solution space arena. 

The closer the solution space maps to our concept of the 
problem space, the better the goals of modifiability, effi- 
ciency, reliability and understandability can be achieved. 
Most of the languages develoved prior to Ada are primarily 


imperative; that is, they provide a rich set of constructs 
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for implementing operations within the solution space but are 
Jenerally weak when it comes to abstracting real-world 
Opjects into that solution space. Additionally, these 
languages require that the real-world voroblem svace, which is 
both multi-dimensional in description and highly parallel in 
effect, ce mapped into a solution space that has a relatively 
Flat topology as well as a nigh dependence on sequential 
processing for solution attainment. 

The Ada language, when viewed through the window of 
Booch's object-oriented design methodology, allows us to 
minimize tne distance between the problem space and the 
solution space by emphasizing the fact that object-oriented 
Gecagmeis NOt a purely functional design technique. Rather, 
it recognizes the imvortance of treating software objects as 
actors, each with its own set of apyvlicable operations. 

The three steps to object-oriented design, along with a 
Beaer description of each, follows. 

ieee orane ene Problem 

At this stage we remain entirely within the problem 
space, and attempt to gain an understanding of the structure 
of the problem space at hand. This step will be iterative, 
working from the general to the specific, and such tools as 
SADT and data flow diagrams are wholly appropriate in 


defining the problem. 
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Z. Develop an Informal Strategy 


Once an understanding of the problem space 1S gained, 
an informal strategy as to how to arrive at a solution is in 
order, where that strategy parallels our view of the real 
world. This strategy is best kept within the realm of 
natural English descriptions and in terms of concepts 
existing in the problem space. In this way intuitive feel as 
to how to solve the problem is not yet lost among the 
complexities of abstraction into the solution space. 

3. Formalize the Strategy 

In this step we finally enter the realin of the 
solution space and incur the need for adstracting from the 
Beoblem space to the solution space. From the informal 
strategy already developed, we first extract the nouns which 
represent objects in the proolem space and then the 
qualifying adjectives which represent attributes in the 
problem space of those nouns they qualify. Nouns in the 
English language can be common nouns (such as table or 
Chair), mass nouns (such as water or fuel), or nouns of 
direct reference (which refer to a specific object in the 
problem space). Adjectives identify the attributes or 
constraints of these nouns, and when such adjectives as 
"concurrent" and “asynchronous” are used in the informal 
Strategy, the parallel nature of the problem space is 


revealed. 
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Having extracted the nouns and adjectives from the 
informal strategy as objects and gualifiers to those odjects, 
meoeectiveiy, we must then extract the verb phrases occurring 
in the strategy. In doing so, we identify the real world 
Operations being performed on those objects in the strategy 
and further associate each operation with a particular object 
in the problem space against which each operation acts. 

Perhaps the most important step in formalizing the 
Strategy involves establishing the relationships among the 
Objects already defined. Sv this it is meant that the visible 
interfaces to each object are identified and formaliy 
described using Ada as the design language. By identifying 
the object interfaces and their relationships (interconnec- 
tions), a contract is formed between tne user of an opnject 
and the object itself, and this contract explicitly defines 
the operations which may be performed on the odject by the 
user. The beauty of Ada is that it not only permits us to 
easily describe such a contract but also enforces the 
Semiem@act by preventing us from violating our logical 
abstraction. 

The contract having been made as to the permissable 
operations useable against any particular object, we can then 
implement those operations in the Ada language. This results 
in operations which are executable, and further allows the 


development of a design for solution to the problem which is 
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also executable. The implementation of operations and the 
design for solution to the problem will naturally reveal 
lower level objects and operations needed to support the 
present level of solution implementation. These lower Level 
objects and operations can in turn be addressed, leading to 
further iterative decomposition until the point is reached 
where further decomposition will not aid in svstem 


understandability. 


D. ADA LANGUAGE TOOLS 

Tne fundamental building blocks of the Ada language ar2 
program units, and every Ada program is made up of these 
Meodream Units [Ref. 8: p. 47]. Hach program unit 185 made up 
OF two distinct parts: a svecification, wnich contains tnose 
entities visiole to otner program units and wnicn ctnus 
defines the external characteristics (interface) of tna pro- 
gram unit, and a body, which contains the implementation 
details of the program unit where those details are not 
VEsitole €o other program units. The specification part and 
the oody of any program unit can be separately compiled, 
which greatly enhances the management of designing an Ada 
software system. This is because at any level of software 
system design, it is only necessary to write the specifica- 
tion parts of the program units used at that level which can 


then be compiled resulting in the creation of an enforceable 


design structure to the problem solution. An added denefit 
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Pemtme Process Or making distinct the specification part and 
body of Ada program units is that it encourages both the 
construction of systems from separately built parts and the 
construction and use of libraries of generally useable 
component modules. 

Ada program units are categorized into three distinct 
areas: subprograms, tasks and packages. Each of these 
categories is explained below. 

1. Subprograms 

Subprograms are the basic units for expressing 
algoritnms and provide the means for naming definable 
functions. They have the characteristic of being sequential 
in execution and can range in scope from being the main 
peogram down to dDeing 2 lowest level moduls. The subprogram 
Specification defines the interface, or calling convention, 
between the subprogram and the outside world while the 
Subprogram body encapsulates the algorithm for which the 
Subprogram exists. The applications for Ada subprograms 
include main program units (the nighest level of an Ada 
software system), definition of functional control (where the 
functions determined at one level of design are implemented 
Via subprogram at the next lower level), and definition of 
type operations for abstract data (where user-defined or 
abstract data types can be linked with unique operations 


regarding those data types). 








Subprograms eve two basic forms: procedures and 
Functions. A procedure provides the series of actions which 
are defined in its body whenever that procedure is invoked, 
and it may have parameters to pass information either to 
Mesetau Or Dack to the invoking unit. A function has the 
Primary purpose of returning a calculated value where that 
value is computed within the function and returned to the 
program unit which called the function. 

2. Tasks 

Tasks are the program units which define overations 
Or precedures which execute in parallel with other tasks. 
Where most existing high-order languages provide little or no 
Support for the parallel execution of program operations or 
procedures, Ada svecifically accomplishes such parallel exe- 
eaclon ehrough the use of tasks. Since the real-world 
problem space overates in a highly parallel fashion (more 
than one event occurring at a time), the task program unit 
serves to greatly reduce the distance between the problem 
space and the solution space by eliminating the need to 
convert real-world parallel events into the serial abstrac- 
tion demanded by other high-order languages. Physically, 
tasks may execute on multicomputer systems, multiprocessor 
systems, or with interleaved execution on a single processor. 
As such, tasks can be seen as individual sequential 


processes, where each process interacts with other processes 








through a sophisticated means of communication and synchroni- 
Zation among individual tasks. The term "rendezvous" applies 
to the place and time at which two individual tasks interact, 
Boalt 15 this interaction among tasks that allows, for 
Mmeobance, One task to detect and report the inaction og 
improper action of another task. Such an aoproach enhances 
communications reliabiliy and error detection within the 
sortware system. 

Like the subprogram and package, the task is divided 


moetO sa EaSK SvdeciEication, which derfinas thre intarface 
Beeveen EnS task and otner pwogram units, and the task Sody, 
Pren COnNSiSts of the task's executable vart. 
3. Packages 

Packages are tne units used for encapsulating ccolilec- 
tions of logically related data, objects and data tvves. The 
package specification defines the interface to the package 
and thus svecifies which parts of the vackage may be used 
and, furthermore, how they may be used. The package specifi- 
cation may ode further divided into a visible and a private 
part, where the visible part declares the package resources 
which may be used outside the vackage, and the private Dart 
which, while textually available to the package user, cannot 
be referenced outside the package. Tne dackage vody is 


specifically ngt accessable outside the package, and contains 
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as £4 


the necessary sequence of statements relating to the package 
purpose. 

Packages are extremely versatile as to their possible 
application, and the logical grouping of objects and data 
types Dlaces the definition of those objects and data types 
mameone Location. iiaes appl i Cajeaionesdime a tapamenhances 
maintainability. For instance, if changes become necessary 
witnin a logical grouping, only the single package need be 
cnanged thus ensuring consistency throughcut the system for 
any program unit calling that package. 

With Doackages it is also possibie to group Logically 
related program units, namely, subprograms, tasks, and even 
other packages. The advantage here is tnat the algorithmns or 
contents of those program units witnin a package can De 
@mangea (fOr, e.g.» reasons of efficiency) without affecting 
Bae ocogram units which call tne vackage, Packages also 
allow the user to uniquely define an abstract data type and 


then encapsulate it in such a way as tO aenforce tne 


rh 


abstraction through the Ada language. Thus where a set o 
Beieaweyoes are Unique to a specific application, those Jata 
types and their application can be placed within a package, 
and that package will then disallow improper implementation 


of those types. 
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m. DATA TYPING 


The objects within the Ada language equate to the nouns 
Pemusee em everyday English. Each object in Ada has a set of 


properties which denotes the kinds of vaiues that the object 


QO 


an 


Q 


arry and the operations which we can apply to that 
object. This set of properties is called the object's "type" 
in Ada. The types applicable to any object in Ada must be 
specifically declared within the software system as these 
Mees dO Not exist implicitiy within Ada as they do in other 
high-order languages such as FORTRAN. Data typing within Ada 
Mas the effect that objects of a given tyboe aay take on only 
M@yose Values that are appropriate to the type and, in 
meeewmemen, cle Only overations that may be 20plied to an 
object are those that are specifically defined for its type. 
Because of this, Ada is recognized as a strongly tvoed 
language. Strong typing within Ada provides a mechanism for 
imposing structure on the data manivdulated within an Ada 
program and, in addition, directly supports several of Ada's 
recognized design needs, including maintainadility, 
Peadaomsibty, Wreliadility and reduction of complexity. 

There are four intrinsic data types witnin the Ada 
language--scalar, composite, access and private types. 
Scalar types include both numeric typdes (including integer, 
Fixed point and floating point) as well as enumeration types 


(which allow the programmer to assign ordered sets of 
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mpecicric €numeration literals to be used as values in the 
program). Composite types include array types, which allow 
the collection of similar or homogeneous objects in an 
indexed form, and record tyves, which allow the collection of 
potentially different or heterogeneous objects within the 
record. Access types ar2 designed to handle those onjects 
which are subject to dynamic change over time and even during 
orogram execution, such as buffer space within a message- 
passing system or geneaological records ina data base. 
Piewbast Category of data typing, the privates type, is 


Ene most inventiv 


(Db 


Oh ida Swdain tio ino ool s. elec ages 
Peecain the Dackage sdecification, the orivate typing of 
Objects serves to hide within the body of the vackage both 
the structure of the data used to define the type and tne 
algorithms which implement the operations on that type. Only 
the names of the private types within a package are visible 
to the users of that package. The primary benefit of vorivate 
™eaoeoers that they support directly the orincipls of 
information hiding wherein the details of an implementation 
are suppressed in order to allow focus on the abstraction of 


lower level modules. 


F. GENERIC PROGRAM UNITS 
One potential disadvantage to Ada's strong typing rules 
is that multiple forms of packages and subprograms may nave 


to be designed in order to process objects of different 





types, even though the algorithms within those vackages or 
subprograms are identical. This is because Ada's strong 
typing rules require us to specify the type of every object 
at compilation time and, if the object's tyve does not "fit" 
mien package or supprogram specification, it will be denied 
entry to that package or subprogram. To deal with this 
problem, Ada has as one of its tools the generic program 
unit. The generic program unit serves as a “orefix" to what 
would otherwise be a non-generic program unit and it allows 
access to the orogram unit for all generic Darameters named 
ti tie generic unit. The benefit o¢ the generic program unit 


1S tnat a general ourdpose program can be written 7S. Olas 


but used many times and by different program units. 


G. INPUT/OUTPUT 

Embedded computer systems nave a requirement that the 
computer communicate with I/0 devices which arse oftimes 
Unigue to that system which has usually required that 
software coding be employed to spvecifically match the 
comouter with its I/O devices. This coding is always tedious 
and costly and almost never portable to otner systems. On 
the other hand, where only one type of formatted I/O is used 
PPomEeeoarsticUular application, most imolementations of 
existing hnigh-order languages will bind a huge routine 
Pesraryeunit that will handle virtually any kind of £Eormatted 


I/O, whether we use those features or not. With Ada there 
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Seeoeoecae ability to build 1/0 routines for communicating 


te: 


with unigue devices and, while the routines themselves may be 
tied to the devices they serve by virtue of device 
uniqueness, the darts making up the routines as well as those 
servicing the routines, are portable. Additionally, Ada 
peeeows £LOr the utilization of redefined units for I/0 of 
common data types which can be selected as needed without the 


need for adding any new language constructs. 


H. DOCUMENTATION 

A Significant advantage to using Ada in a software 5s 
design is that the means of documenting the structure of the 
system ultimately becomes the same means with which the 
System is implemented. In fact, where Ada is used as botn 
the design and implementation language within a system, the 
merece SUCMN Malntenance is am integral part of the 
implementation process. Thus, whereas with other design 
processes tne design is documented in a form wholly different 
from the implementation language and thus requires a two Dart 
effort in design maintenance or change, with Ada every change 
in the Ada implementation will, in principle, update the 
documentation commensurate with that change. Additionally, 
Since Ada is a highly structured language, it is easy to 
maintain the original structure of the svstem while modifying 


the underlying pieces. 
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fee Girs CYCLE ISSUES 

Paouldnmwomly a vecy Smallwparteotestnemwrrtcass and tools 
inherent in the Ada languag2 nave oeean touched uvon here, it 
can be seen that the underlying philosopchy behind Ada as well 
as the implementation tools available with Ada combine to 
rorm a scftware language system that will greatly enhance the 
ability to manage Ada software systems over their life 
cycles. Traditionally, software developers have taken a 
restricted view of the life cycie process and nave treated 
each pnase of a system's life cycle as an independent part. 
Pweeowna>ofOact Aas ilsad §€5 Aumerous problems, including 
configuration control nightmares and sets of software modules 
Beate would not Fnnction together. In the end, ths developers 
would complete the svstems they started, although probably 
not on time and not within oudgek. 

Ada will not solve the software crisis oy any stretch of 
the imagination. It will, however, avert the transition of 
Mmieteeecrhsis into a software catastrophe if it is 
exoeditiously and judiciously applied to prospective and 
future software development projects. It will do this by 
allowing all levels of management and implementation to 
maintain control over the systems they are tasked to develop, 


where that control today is in large part absent and sorely 


needed. 
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V. UTILIZATION OF ADA AS A PROGRAM DESIGN LANGUAGE 


A. PRESENT UNDERLYING PROBLEMS 

The discussion of different private endeavors to design a 
usable PDL presented in Chapter III points to a revealing and 
somewhat distressing fact: there is apparently no consensus 
as to what an Ada PDL should consist of or now it snould be 
ised. For example, where the Harris PDL supports all 
Mmeaeuees Of the Ada language and in fact incorvoorates two 
additional non-Ada constructs to add clarity, the IBM PDL is 
a strict subset to the formal Ada language, and tne TRW and 
Norden PDLS allow annotations to the Ada language for use as 
eee rais lack of consensus 15 Furtner exemoalified oy the 
Tact tnat at least one vendor does not consider tne acroayn 
Seely as meaning program design language (in tne case of 
Harris, the acronvm means "process description language"). 

One is Forced to ask under these circumstances wnether 
present attempts to design and construct an effective and 
usable Ada PDL are approaching that end in the most effective 
Manner. Of course the answer to this question is that tne 
individual efforts, however different tney may be from one 
another, each have attributes which contribute positively to 
the desired end goal of creating an Ada PDL. It 18 not yet 


known which, if any, of the mentioned vendors' designs will 
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be adopted ody DOD, or whether a combination of design 
attributes From among several vendor designs will be adooted. 
What can be said about the different designs mentioned is 
that there is a common thread of enthusiasm and support among 
vendors that they key elements of the Ada language directly 
Support tne process of program design. 

But enthusiasm alone does not beget a usable end product, 
Darticularly in the area of software davelopment. Pae 
Management of a software development project is perhaps no 
different than the management of other large engineering 
Bmegectes, except that the end product is certainly 
Sangtote than, say, a bridge or a ship. An ideal situation, 
and one that would greatly simplify the management o€ 
software engineering, would be the existence of an automatic 
orogram generaticn system as the ultimate PDL, but of course 
the discipline of software engineering nas not yet progressed 
Eo Ehat point. What is needed, then, 1S a program design 
language shat will maximize the nanageability of any software 
system development where the primary tool used in tnat 


development is the PDL adopted. 


B. AN EXAMPLE OF PDL/ADA IN PROGRAM DEVELOPMENT 

Perhaps one of the most revealing studies into the 
problems inherent in the design and implementation of a PDL 
waS a study conducted by General Electric and the University 


of Maryland under contract with the Office of Naval Research 
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(ONR) in 1982 [Ref. 12]. In this study an attempt was made 
to systematically measure some of the major problems 
associated with a software development project through the 
vehicie of actually having a program design team develop a 
mock project utilizing Ada as a PDL. Following an intensive, 
month-long training program into concepts and cperations of 
the Ada language, a three-member program design team set out 
to design a portion of a working ground support system for 
communications satellites. The system was already in 
existence in the programming language FORTRAN, and one intent 
Of the study was to compare both tne time and effort in 
development as well as the functionality of the end-product 
program with the existing FORTRAN program. 

The program develooment process was divided into two 
distinct phases. The first phase was the design phase and it 
involved creating a brief description of each Known component 
in the system. This design phase was intended to be written 
in compilable Ada, vice flowcharts or other means, and as 
such this phase encouraged the use of the entire Ada language 
inventory as a PDL. The second phase involved writing a more 
Breeisce design, including specific algorithms, complete 
interface specifications, the definition of ali data types 
and the declaration of all data objects. Following the 
second phase each design component was coded in Ada resulting 


in an executable software end product. 


74 





The use of two distinct design phases was not initially 
set out as a requirement in the design of this program. In 
Fact, at First the design team was given a free hand as to 
their design style, and they began the program design vrocess 
with only one design phase intended. It was recognized 
almost immediately, however, that when the vDrimary emphasis 
was to design uSing compilable Ada, the resulting design 
evolved as increasingly detailed threads of functionality 
rather tnan as complete descriptions of the system at each 
level. That is, each team member tended to follow one 
Pminecron EmM@rouga the various design levels, filling in 
Greater detail at eacn lower level for that vbDarkicular 
MUncGNuOnh, 2athner chan providing a complete description of the 
system at each level before attemoting further refinement at 
lower leveis. As a result of this tendency at vertical 
program development vice norizontal development the two- 
phased design approach was imposed, and it was with this 
approach that the problem ran to completion. An additional 
problem was recognized after the final program design was 
completed. While the final design was judged to be a good and 
workable design, it was characterized as being a highly 
functional one and one very similar to the original FORTRAN 
based system, even though the design team had no direct 
access to the original FORTRAN design. While this may not at 


first seem to indicate a fundamental problem with the final 
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design, it does raise two issues regarding that design. 
First, the design indicated a failure to take full advantage 
of the design power inherent in the Ada language, and second 
the question iS raised as to whether an alternative design 
approach was not considered, such as Grady Booch's object 
Oriented design methodology [Ref. 3]. Although examples of 
data abstraction and encapsulation were presented in the Ada 
training course, the emphasis was placed on language features 
that support those ideas rather than the ideas themselves 
Gecina@eeamning. As a result of the Ge ess Oe ELS 
@ensider Yalternative design approaches in this problem, the 
study concluded that a more expansive training program would 
be advisable in future programs of this nature. Sue hea 
training program would specificaliy address alternative 
design approaches since a choice of alternatives impacts the 


initial design decisions and perhaps even the requirements 


analysis phase. 


C. MANAGEMENT ISSUES 

From the discussion of underlying problems and the 
example of an Ada deSign project presented above, it becomes 
apparent that some fundamental management issues must be 
addressed before Ada (or any other new programming language) 
can be specifically implemented as a program design language. 


Some, though not all, of those issues follow. 
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1. The Need for Education 

The General Electric/University of Maryland study 
reveals one of the most important management issues which 
must be specifically and comprehensively addressed before Ada 
can be adequately designed into and utilized as a PDL--the 
need to re-educate designers in the Ada language. The primary 
reason for this need is that virtually all of today's 
programmers and program analysts were trained to understand 
the conventional process oriented-design methodology as the 
only means with which to design or program computer software. 
While process-oriented design is not in and cf£ itself "bad" 
design methodology (it has been the primary means of software 
design since the onset of the computer age), it does nave 
Perit attoemoel1 Lessa®>plibation to program design primarily 
because it focuses attention on "how" processing is taking 
place rather than on "what" is being processed. The usual 
result of this focus has been that vrogram designers have 
tended to devote too much energy toward the intricacies of 
the software itself while losing sight of the overall purpose 
for which the software was created. Such a focus usually 
results in software that is so overly complex and interdepen- 
dent as to require the injection of patchwork languages just 
to get the software system to work, with a resulting product 
that is all but unmanageable. This is the single most iden- 


tifiable cause of the present software crisis. 
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If the tools available in Ada are to be effectively 
utilized in the design of a PDL, then those responsibdle for 
that design must be highly versed in the object-oriented 
design strategy and methodology. The snift in one's thinking 
away from process-oriented design and toward object-oriented 
design requires more than a shift in method or technique; it 
requires a fundamental shift in software design philosophy. 
mire required snift in Eninking is so fundamental, in fact, 
that some nave argued that the untrained might be easier to 
educate in the object-oriented design methodology than those 
already trained in process-oriented design [{Ref. 13]. There 
is a clear need, then, to ensure adequate education for the 
designers and users of the Ada PDL, as well as for the users 
Of Ene language itself in applications programs. 

2. The Need for Standardization 

Clearly the present software crisis will only be 
replaced by a new software crisis if adequate controls as to 
Standardization are not enforced in the Ada environment. 
Each of the four vendors mentioned in the SofTech study hada 
unique approach as to what a PDL should do, and how to design 
a PDL in the Ada language [Ref. 10: p. 3-18]. Somewhat 
distressing is the fact that two of the vendors introduced 
annotations to the Ada language in an attempt to create their 
respective versions of an Ada PDL, which suggests the 


possibility that a whole new group of branch languages might 
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eventually evolve from the present Ada language. Ons of tna 
basic precepts to the creation of the Ada language was to 
SeisecOtUmage such Dranching in an effort to maintain 
manageadility and maintainability of Ada software. 

In designing an Ada PDL or any other Ada based 
software, it iS imperative that we not lose sight of the 
Original intent of the language as put forth by the HOLWG-- 
Piatp Ouse alataining standardizataon of the language's 
application. Some diversion from the original language may 
BebeieGessary in OfFder Ehnat a workable end product be 
deveioped, Sut that diversion snould at all costs se kept to 
a minimum. 

Senco cco ron Horrzontal Vice Vertical Design 

Ada has been described as an ideal tool in the design 
of both program design languages (PDLsS) and system design 
languages (SDLs) [Ref. 14]. Where a PDL describes how each 
component in the software system is to be constructed 
Cane seadinagucOontrol fLlow),.,an SDL description shows what 
components need to oe constructed and what interfaces eacn 
comoonent provides and requires. Tne two Features of Ada 
wnich distinguish it from otner languages and which make it 
an ideal program and system design tool are that it is an 
Object-oriented language and that all packages and 
subprograms are broken down into specifications and bodies, 


each of which are separately compilable. 





The beauties of an object-oriented design structure 
nave already been touched upon--they discourage designers 
from getting "lost" in the intricacies of the solution space 
while forgetting the purpose for wnich the software system 
was created in the first place. The primary Deauty of 
separate compilability between specifications and bodies is 
that it allows the emohasis to be placed on horizontal 
development within a system or component prior to the need 
For vertical development within that system or component. By 
mo Laconacie development, LE is meant that all elements or 
components existing within acertain level of heirarchical 
structure could be specified and developed as needed within 
that level of heirarchical structure orior to the need for 
developing other lower level comvonents and structures. The 
fact that package and subprogram specifications and bodies 
can be sevarately compiled allows a tremendous amount of 
design freedom as well as a true simultaneous top-down- 
bottom-up design that enforces a modular and component 
discipline on the system designer and system implementer. [It 
also allows a system designer to remain within the confines 
of the heirarchical level in which he was tasked to design 
without being overly concerned with the implementation 
detaiis of a lower level upon which his heirarchical level 
will ultimately depend. An example of where separate 


compilability of program specifications and bodies can be 
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used is in the process of prototyping; where a simple and 
very high level system structure could be designed using 
program specifications as 'stubs' in place of tne called 
program units. In this way the correctness and comoleteness 
@emeeme initial design structure could be verified through 
compilation at a vary early state in design and with a mini- 
mal investment of effort or time. Whether used in prototyping 
or other design strategies, the separate compilability fea- 
ture of Ada is in direct support of the software engineering 
Drinciples of abstraction and information niding, and further 
directly supports heirarchical design methodologies. 

As revealed in the General Electric/University of 
Maryland study, however, the Ada language in and of 1tself 
will not svecifically orohibit non-conformance with a 
nhelrarchical design structure; it only encourages its uSe. 
The enforcement of heirarcnical design must in the ena be 
considered an essentially Numan endeavor, and perhaps the 
mest Valuable tool to use in this endeavor is that of 
structured walktnroughs during each phase of program or 
system development. Thus at any level of heirarcnical 
design, the specifications of packages and subpdDrograms within 
that level could be developed horizontally until the entire 
level was complete, after which that level could undergo the 
mrocess of structured walkthroughs and svecification 


Semen lation within that level. Only after it was 
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demonstrated that the level was complete and operable as to 
the various Operations occurring within that level would the 
element of vertical development take place. That is to say, 
after it has been determined that the specifications within 
the present level of development are complete and operable, 
the program bodies belonging to each compiled program 
Specification could then be developed. Of course once the 
vertical boundary between specification and body was crossed 
(a new level of heirarchical structure entered), the 
horizontal develooment requirement would have to be rea- 
imposed within that new level, and the process of 
development, walkthroughs and compilation of program bodies 
(and specifications of even lower level program units called 
Homanmcesutit Of those bodies), would begin anew. Pris 
iterative process would continue ina horizontal-vertical- 
moaezontal fashion umtil the entire ee eras complete. 
Regardless of whether Ada is utilized as a PDL or as an SDL, 
the need to employ this iterative, vertical-horizontal- 
vertical technique remains if the true value of Ada's 
features are to be realized in system design. 
4. The Need for Support of Software Principles 

In the design of any software system or of a PDL or 
SDL for utilization in the design of software systems, the 
fact remains that the software engineering principles of 


ASoeedeereom s,m neEOrmation hiding, modularity, localization, 
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UmErOrmity, completeness and confirmability must be 
maintained. Since it 1S people and not machines or languages 
that ultimately perform the process of software design, 
regardless of the programming or design language used, it is 
incumbent upon the people involved in system design, to 
ensure that these principles are continually enforced. As 
such, the enforcement of these principles is a management 
issue and not a language design issue. 

The use Of Ada as a PDL or SDL is not, after all, a 
design methodology in and of itself, but rather simply a 
metnod Sy which design can be represented. Put another way, 
Ada as a PDL is a concise and meaningful way to put down what 
Poeltietno mind Of the designer but 1t will not by itself 
“perform the design process. Ada wili, however, gx2a 
enhance the design process by virtue of the fact that it, 
more than any other language available, directly supports the 


software vorinciples mentioned above. 


D. LANGUAGE DESIGN ISSUES. 

In addition to the management issues mentioned here, 
which are in effect applicable to the design of any software 
System, PDL or SDL, regardless of language implementation, 
there are specific language design issues which must be 
addressed prior to incorporating the Ada language into a 
specific SDL or PDL. At present there exists no Single Ada 


based SDL or PDL as the accepted design within the DOD. 
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However, aS mentioned in Chapter III, a number of ongoin 
development projects are underway under the auspices of DOD 
contract. While the projects differ in varying degrees as to 
language specifics, the aodproaches taken bv the diffffacent 
vendors involved are quite similar. All, for instance, make 
use of the major Ada language features, though each makes use 
of those features at varying levels of implementation and 
emrect. 

in attempting to examine which Ada based PDL the DOD 
should ultimately adopt for use, it is apvoropriate tc 
consider the necessary and desired features cto include in 
that PDL, as well as the support environment within which the 
POtee will exist. The remainder of this cnapter will be 
devoted to an examination of these features. 

Pree hed ’Piwsonould be Applications Flexible 

An Ada PDL snould be versatile enough so as to allow 

1ts application at all levels of program design and 
develooment, regardless of orogram type or coding language. 
For example, if a design team is utilizing an Ada PDL in the 
design of a complex missile launch and guidance system, the 
use of the Ada PDL tool should not be constrained to any 
Bartieulam level or group of levels n the design hneirarchy, 
out should instead be design-level independent. As such it 


should allow short-iteration vorototyping at the highest 


levels of design while simultaneously supporting design of 
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the system's lowest level modules. Only with such design 
level indevendence will the Ada POL allow trua tov-down- 
bottom-up system and module design. 
2. An Ada POL Should Not Subset the Ada Language 

By this it is meant that an Ada based PDL should 
recognize the entire Ada svntax, rather than a subset of that 
syntax. The reason for this is that an Ada PDL which subsets 
the Ada language serves to restrict the available use of that 
language to the extent that the PDL is subsetted. In the 
Same manner in which a person who relies solely on a vocket 
dictionary of the English language denies himselfF of many of 


Mme rica English words and constructs available in amore 


a) 


somprehensive dictionary, an Ada PDL which subsets the Ad 
language denies its users of some of the ricnness available 
in tne Ada language. 
S. poaneeda PDE Should Include English Narratives 

One major difference Setween most PDL's and high- 
level languages is that the PDL's use narrative text embedded 
directly within tneir statements. The vdourpose of this 
narrative text is to enhance understandability of both tne 
individual statements and the design language as a whole. 
Another benefit is that since each PDL statement can be 
explicitly described to the user via a standardized narrative 
text format, there is far less confusion as to tne purpose 
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Standacdization serves to enhance the maintainability and 
transportabdility of both the PDL Language itself, and the 
software systems and modules whose designs are a product of 
the PDL. 

The use of English narratives serves also to 
encourage abstraction, the omission of implementation details 
where those details are unimportant to the present 
heirarchical level being designed. For examole, if a 
Orototype system were being designed using an Ada PDL, only 
the svecifications to those program units being called by the 
prototype need be identified, with tne associated progran 
unit oodies being descrivsoed oniy generally within tne 
nacrative text attached to the specifications. When the 
orototvpe was comolete, it could then: be compiled and checked 
for completeness and correctness as to tne prototynve alone 
and without regard for lower level implementation details. 
Once verified as complete and correct, those lower level 
details could be addressed, using the narrative text as a 
Seder ng. point. In this way, narrative text provides an 
effective vehicle with which to iteratively progress from a 
high level design to succeedingly more detailed program 
descriptions existing at lower levels in the system's 
neirarchy. 

Unlike most other PDL's, an Ada based PDL allows the 


simple and safe inclusion of English narrative text without 
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effecting compilability of the PDL or its statements. As 
such, it is most important that an Ada PDL include extensive 
use of narrative text, and that that narrative text encourage 
abstract design level description rather than detailed 
Searwng. 
4. An Ada PDL Should Allow Annotations 

An Ada PDL should include a mechanism for expressing 
annotations which extend the Ada language in its application 
to a PDL. A primary purpose of annotations is to allow the 
expansion of Ada's KEYWORD dictionary so as to better match 
Mien agretrOnary to the particular needs of the PDL 
ape! cation. Annotations would best pe used to provide 
additional design information or to impose requirements on 
che designer, such as specialized forms of Ada comments. It 
is not suggested that a specific set of annotations be 
adopted, but rather that a standard mechanism be identified 
to indicate annotations and that the use of annotations be 
encouraged in program design. The placement of specific 
annotations could be required to occur as a preamble to a 
design module or to precede particular PDL statements where 
appropriate. In addition to a standard means with which to 
express annotations within the PDL, a common Ada PDL 
processor which recognizes the annotation format and calls 
appropriate subroutines could be designed so as to ease the 


expandability of the annotation inventory. 
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There is of course a danger in the unchecked 
expansion of an Ada PDL through the use of annotations in 
that without some control, the PDL to which those annotations 
are added can become overlv complex and ultimately 
unmanageaDdle. Thus whereas annotations would provide a 
valuable tool in the flexibdility of an Ada based PDL, their 
use should be judiciously controlled. 

>. An Ada PDL Should be Supported by Automated Toois 

One of the most valuable elements to be inciuded in 
rhe Ada PDL anvironment would oe that of an extensive 
automated tool inventory to assist in error-checking, design 
formatting and design editing. The Minimal Ada Programming 
Support Environment (MAPSE), as defined by the STONEM 
document, suqgasteq that certain teols be included in the Ada 
language support inventory text editor, compiler and linker. 
As a minimum requirement to the Ada PDL support environment 
tnere should be an Ada compiler so as to ensure proper usage 
of the Ada language and minimize CPU time investment during 
program design. A PDL processor would be preferred over a 
compiler since it would allow the pvrocessing of annotations 
as well as the checking of errors in such a way as to report 
those errors in a manner compatidle with design rather than 
implementation. Examples of errors that would be reported 
with a PDL processor are undefined subprograms or variables 


appearing in the program design. A third valuable tool would 
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be that of an Ada PDL text editor, where the purpose of such 
an editor would svecifically be to encourage design rather 
than code in developing Ada PDL descriptions. 

Another tool that could be of considerabie value in 
the management of vbrogram design would be a graphics 
generator capable of generating data flow diagrams (DFD's), 
input-orocessing~output (IPO) charts, and flowcharts directly 
from the program bdeing designed. Whnile such a tool would 
vperhaos need to be quite complex in order to perform the 
Pu@mMetion Of creating graphics directly from vdrogram code, the 


See ttasseosstole ErOm Naving autonatically generated 


‘ey 


Dictorial representations of programs under design are 
substantial. There is, for instances, verhapds no oetter way 
to convey the structure and purpose of a complex sottware 
Pecodram Grom One AUMan being to another than through the 
won@mere OF DED Ss and [PO charts representing that porogram. 
An additional benefit of having an automatic graphics 
Zenerator would be the ability to 'stand bdback' and view a 
graphical representation of the system under design at any 
@gesired point im time. Scams oacure would further 
contribute to the proper placement of emphasis on the 
Management of program design over the concern for 
implementation details, thereby helping to maintain control 


over the design process. 
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Regardless of which of the automated tools mentioned 
are developed for use with an Ada PDL, the Ada language is 
unique in its ability to support such tools once they are 
developed. The reasons for this lie primarily in Ada's 
strong typing and ability to support separate compilability 
of program unit scecifications and bodies. Since all objects 
in Ada are explicitly defined and all interfaces specified, 
the task of creating a program structure and then cnecking 
Mates SeEELUCEWre™= for Completeness and correctness i158 
Sigmmercm@eantiy simplified, whnetner that task is Derformed 
manually or by machine. 

6. An Ada PDL Should de Well Documented 

Adequate documentation 15 a necessary 2lement to any 
PDL, and an Ada based PDL iS no exception. Documentation in 
the case of an Ada PDL should include a requirene2nts 
document, an Ada PDL reference manual, an Ada PDL users guide 
and an Ada PDL Drocessor users manual. These documents will 
be needed to establisn a philosoohy of Ada PDL usage and will 
be necessary For prover use of the Ada POL. In addition they 
will serve to promote tne wide-spread use of the Ada PDL for 
program design. 

Bmeaddilitional form of documentation exists in the 
narrative text section of appropriate Ada statements, in that 
this narrative text serves in part to explain to the user tne 


Function and purpose of the associated Ada statement. In 
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this sense Ada 1s a self-documenting language, and the 
advantages possible through this self-documenting €2ature 
cannot be overstated. If, for example, a program designer 
using an Ada PDL was unsure as to the function of any 
Darticular statement within the PDL, he should be adle £9 
determine that function almost inmediately simolivy ov raading 
the narrative text attached to the statement. If he were 
still unsure, he could then consult the appropriate external 
publication, thougn such external consultation snould be 
unnecessary if the tool of narrative text is exploited fully 


oy cne designers of the Ada PDL. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

Perhaps the single most important contributing factor to 
the present software crisis has been the failur2 on the vdart 
of software programmers and program designers to maintain a 
proper pversvective on the need for management of the software 
projects tney are tasked to accomplisn. This failure isin 
oart due to the Fact that inadequate nanagenent styl2 has 
Sean the rule rather than the exception, regardless of thre 


software project involved or design language used; and in 


=e 


Peeeeecuemca tne fact that, until Ada, there has been no 
language that tended to encourage a proper management style 
Simoly by virtue of language design. 

The intent of this tnesis has deen First to explore the 
genesis of the present software crisis, to explore the 
various tools available in the Ada language which could be 
used to help avert future crises in software development, and 
lastly to address the appnolicability of the Ada language to 
Peowoteolric FOle aS a Orogram design language. It can ode 
concluded from the points raisedin this thesis tnat Adaisa 
far petter candidate for implementation as a PDL tnan any 


other language presently in existence, and that the DOD 
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Seu gd Olace a very Aigh Driority on the design and 
implementation of the Ada language as a PDL. 

Another important conclusion that can be drawn from tne 
Pemimesmsaltsea in this thesis is that a definite shift in 
management policy and procedures must take place bdDeforée the 
software crisis can be totally overcome. That is, management 
must shift its philosophy away from tne perspective where 


piecemeai verticai software design and maintenance is 


Ou 


tolerated: toward the perspective where comprehensive an 


nocizontal design management is enforced. 


B. RECOMMENDATIONS POR FOLLOW-ON WORK 
The autnors recommend research be conducted at tne Naval 


Postgraduate School in tne following areas: 


= Utilization of Ada as a design language for use in 
embedded weapons systems such as Harpoon and Tomahawk. 
-esmmiggenresearcn into USe Cf Ada PDL as a compilaple or 


non-compilable design language. 
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APPENDIX A 


GLOSSARY 


ABSTRACTION: The process of viewing a problem at a level 
of generalization where that level of generalization does not 
consider irrelevant lower level details. Abstraction can be 
lixened to a "black box", where the person using or viewing 
EOD ladec DOX 1S Concerned Only with the functions of the 
black box as a whole and is not concerned with the elements 
making up the box. The use of adstraction allows one to view 
concepts and terms in the problem environment without having 
to transform them to the more detailed and less familiar 
solution environment. 

ABSTRACT INTERFACE: Allows inputs into or outputs from a 
module to match changes in inputs or outputs so as only to 
effect the abstract interface code and not lower level code 
within the module. 

ACCESS TYPE: A type whose objects are created by 
execution of an allocator. An access value designates such 
an object. 

BOpY: A program Unit defining the execution of a 
Subprogram, package or task. A body stub is a replacement 
for a body that is compiled separately. 


BUBBLE DIAGRAM: See Data Flow Diagram (DFD). 
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CHARACTER: Any of the ASCII symbols that are used to 
form source Ada programs or are used as data. Graphic 
characters have a visible representation, while control 
characters have visible attributes that are implementation 
defined. Source programs are built from the graphic 
Characters plus control characters which designate passage to 
anew line. 

COLLECTION: The entire set of allocated objects of an 
access tyve. 

CORRECTNESS: A Ponodram 15 cerrect if lt voertorns 
properly the functions it was intended (specified) to do and 
nas no unwanted side effects. 

COMPILATION UNIT: A program unlit presented fcr 
SSmerlacion aS an im@esendent text. It is preceded dy a 
context specification which names the other compilation units 
On which it depends. A compilation unit may be the 
specification or body of a subprogram or package, including 
Generic unmitswor subunits. 

CONTEXT SPECIFICATION: Prefixed to a compilation unit, 
defines the other compilation units upon which it depends. 

CONVERSION: The process of translating from one type to 
another. 

COUPLING: A measure of the relative independence among 


modules. 
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DATA FLOW DIAGRAM (DFD): A graphical tool used to depict 
data (information) flow within a system and between modules. 

DECLARATION: Associates an identifier with a deciared 
entity, including objects, types, subprograms, tasks, renamed 
entities, mumbers, subtypes, packages, exceptions, and 
generic units. 

DEBUG: The process of detecting and correcting errors in 
a procedure, system, process or module. 

DECLARATIVE PART: A sequence of declarations and related 
information such as suborodram oodies and representation 
specifications that apply cver a region of program text. 

DERIVED TYPE: A type whose operations and values are 
taxen From those of an existing type. The existing type is 
Calied tne parent type. 

DISCRETE TYPE: A type with an ordered set of distinct 
values. The discrete types are the enumeration and integer 
types. Discrete types may be used for indexing and iteration 
and for choices in case statements and record variants. 

EMBEDDED COMPUTER SYSTEM: A computer system that forms 
part of a larger system whose purpose is not primarily 
computational, such as a weapons system or process controller. 

EMBEDDED PROGRAM: A computer program that is Dart of 
some larger entity and essential to the proper operation of 


Bice emt ity. For example, the program which serves to 
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identify different aircraft in flight is embedded within the 
aimamtratlLiemcontrol system. 

ENTITY: Anything that can be named or cenoted ina 
program. Objects, types, values and program units are all 
entities. 

ENTRY: Used for communication between tasks. 
Externally, an entry 1s called just as a subdprogram is 
Galed. 

ENUMERATION TYPE: A discrete type whose values are given 
explicitly in the type declaration. These values may De 
either identifiers cr character literals which are considered 
enumeration literals. 

EXCEPTION: An event that causes susvension of normal 
orogram execution. An exceodtion handler is a dDiece of 
program text which specifies a response to the exception and 
the execution of such a program text is called handling the 
exception. 

BXECUTE: To carry out an instruction or to Berrorm a 
routine or set of routines. 

EXPRESSION: Part of a program that computes a value. 

FLOWCHART: A graphical tool used to show sequence and 
Conerel Of Pregiram Or module logic. 

FUNCTION: The name given to one or more statements that 


perform a specific task. 
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GENERIC PROGRAM UNIT: A subprogram or vackage specified 
Wiktinhy ea waenerdiceacpart. A generic clause contains the 
declaration of generic parameters, which may be types, 
subprograms or objects. In the generic specification these 
are called generic formal parameters. When the unit is 
instantiated the formal parameters are matched with the 
actual parameters. A generic program unit may be thought of 
as a possibly parameterized model of program units. 
Instantiated program units define subprograms and packages 
that can be used directly in a program. 

IDENTIFIER: One of the basic lexical elements of tne 
language. An identifier is used as the name of an entity or 
a reserved word. 

TNFORMATION HIDING: Svecification and design of nodules 
such that information (procedures and data) contained within 
a module are inaccessible to other modules whicn have no neea 
to know the information. 

INTERFACE: Communication between modules governed by a 
set of assumptions one module makes about another. 

LEXICAL UNIT: One of the basic syntactical elements 
making up a program. A lexical unit is an identifier, a 
number, a character literal, a string, a delimiter or a 
comment. 

LIBRARY UNIT: A compilation unit that is not a subunit 


of another unit and which belong to a program library. 
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MAINTENANCE: The phase in a system's life cycle 
Following development, acceptance and installation. 

MODULE: A separately addressable element within a 
program. 

MODULAR DESIGN: A logical partitioning of software into 
elements that perform specific functions or subfunctions. 

OBJECT: A variable or constant. An object can denote 
any kind of data element, whether a scalar value, a composite 
value, or a value in access type. 

PACKAGE: A program unit specifving a collection of 
related entities such as constants, variables, types, and 
subprograms. The visible part of a package contains the 


entities which may de used from outside the package; while 


ae 


rr 


Siemon v2.2. Dart Ccometains structura details that ar2 
irrelevant to the user of the package but complete the 
Specification of the visible entities. The package body 
contains the implementation of subprograms or tasks (possindiy 
Other packages) specified in the visible Dart, 

PARAMETER: One of the named entities associated with a 
subprogram, entry, Or generic program unit. A formal para- 
meter is an identifier used to denote the named entity in the 
unit body. An actual parameter is the particular entity 


associated with the corresponding formal parameter in a sub- 


program call, entry call, or generic instantiation. 
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PRIVATE TYPE: A type whose Structure and set of values 
are clearly defined but not known to the user of the tyve. A 
private type and its applicable operations are defined in the 
visible part of the package. 

PROGRAM LIBRARY: Part of the Ada program support 
environment data base recognized by the Ada compiler, 
Sonsistingwor a collection of compilation units. 

PROGRAM UNIT: Any of the three orimary structures making 
up an Ada system; namely, subprograms, packages and tasks. 

RANGE: A contiguous set of values of scalar tyve. A 
range is specified by giving the lower and upper bounds for 
the values. 

RENDEZVOUS: The interaction that occurs between two 
parallel tasks when one task has called the entry of the 
other task and a corresponding accept statement is boeing 
executed by the other task on behalf of the calling task. 

REQUIREMENTS ANALYSIS: The third step in the software 
engineering procedure and the last step of the planning 
phase. Describes the software by identifying the interface 
details and an in-depth description of functions; determining 
Geemoanmmmeconstraints and defining software validation 
requirements. 


ROBUSTNESS: The ability of a program or software system 


to handle unforeseen environmental changes (such as hardware 
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meer) eanamcaemands (such as data) in a “graceful” or 
reasonaole fashion. 

SCALAR TYPES: A type whose values have no components. 
Scalar types comprise discrete types (enumeration and integer 
types) and real types. 

SOFTWARE ENGINBERING: Software implementation of a 
problem solution approached by uSing a set of techniques that 
are application independent. These techniques are: (1) a 
well-defined methodology that addresses a software life cycle 
of planning, development and maintenance; (2) an estabdlished 
set of software components that documents each step in the 
life cycle and shows traceability from step to step; and (3) 
a set of predictadDle milestones that can be reviewed at 
regular intervals throughout the software life cycle. 

SOFTWARE PLAN: The second step in the software 
engineering vrocess. Provides a framework enabling the 
manager to make reasonable estimates of resources, cost and 
schedule. 

STATEMENT: As opposed to a declaration which defines an 
entity, the execution of a statement causes some action to be 
performed. 

SUBPROGRAM: An executable program unit, possibly with 
Paramevers for communication with its point of call. A 
Subprogram declaration Specifies the name of the subprogram 


and its parameters; a subprogram body specifies its 
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execution. A subprogram may be a procedure which performs an 
aGeuonwor a EuUnction which returns a result. 

SYSTEM: A collection of elements related ina way that 
allows accomplishment of some tangible objective. 

SYSTEM DEFINITION: First step in the software planning 
phase where attention is focused on the system as a whole. 
Functions are allocated as to hardware, scftware, and other 
System elements based on a preliminary understanding of 
system requirements. 

TASK: A prodram unit that may operate in parallel with 
other program units. A task specification establishes the 
mame of the task and the names and parameters of its 
entities, while a task body defines its execution. A task 
ee = eee on eee mer nits th] subsequent 
declaration of any number of similar tasks. A task is said 
to depend upon the unit in which it is declared (subprogram 
body, task body or library package body). A unit is not left 
until dependent tasks are terminated. A task is completed if 
it is waiting at the end of its body for any dependent tasks 
Or is aborted but not yet terminated. A completed task 
Cannot be called. A terminated task is, in a sense, the same 
as a dead task (it is no longer active). 

TYPE: Characterizes a set of values and a set of 
operations apolicable to those values. A type definition is a 


language construct introducing a new, unique type, whereas a 


102 





PPE yoemreredttes a2 Compatible (possibly) constrained 
Gefinition of the base type. A type declaration associates a 
mame with a type introduced oy a type definition. 
VISIBILITY: At a given point in the program text, he 
declaration of an entity with a certain identifier is said to 
be visible if the entity has an acceptable meaning for an 


occurrance at the point of the identifier. 
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APPENDIX 8 


ACRONYMS AND ABBREVIATIONS 


APSE - Ada Program Support Environment 


DARPA 


Defense Advanced Research Projects Agency 
DFD - Data Flow Diagram 


HARRIS/PDL - Process Description Language 


HOLWG - High Order Language Working Group 

KAPSE - Kernel Ada Program Support Environment 
MAPS& - Minimal Ada Program Supvdort Environment 
ONR - Office of Naval Research 

PDL - Program Design Language 

RFP - Request for Proposal 

SDL - System Design Language 
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SPrPENDE x  C 


PDL VS. ADA COMPARISON 


Language Features HARRIS TRW 13M NORDEN 
Commentary: 
Comments: x = Xx X 
Pragma: = X = = 


Declarations: 
Types 


Scalar Types: X Xx Xx x 
Array Types: X X ry X 
Record Types x Xx Xx X 
access Types: X A A is 
Bervace Tyoes: x x x x 
Derived Tybes: X X x - 
Sub ny nes: x X x X 
Limited Private: a X X X 
Object Declarations: 
Simple Declarations: < as “ AC 
Array Declarations: X x mm Xx 
Discriminants and Variants: 
Names & Expressions 
Attributes: Xx X X Xx 
Slaces : x x X us 
Aggregates: y.4 X X X 
Expressions: X x x X 
Type Conversions: x - x - 
Qualified Expressions: X X x x 
Overloading Opertors: X X X x 
Allocators: X X - X 
Statements: 
Label: X x ~ X 
Assignment: x - X x 
If (ELSE-ELSIF) : X X P X 
Case: X X X Xx 
LOop: X X - X 
While: X X X X 
EOE: Xx X X X 
Blocks: P X X X 
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Gxt s 
Return: 
Goro: 
Mull: 


Subprograms: 
Procedures: 
Procedure Call: 
Functions: 
Function Call: 
Positional Parameters: 
Named Parameters: 


Packages: 
Specification: 


TaSkKing: 
Task Types: 
Entry: 
HeCept: 
Delay: 
Selective Wait: 


2onagicional Entry Call: 


Timed Entry Call: 
Abort: 


Program Structure: 
Compilation Units: 
Subunits: 

Withs 


Exceptions: 
Handlers: 
Raise: 
suppress Pragma: 


Generics: 
Subprogram: 
Packages: 
Instantiation: 
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Representation: 


Length: 
Enumeration: 
Record: 
Address: 


Machine Code Insertion: 
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~*~ 


P : 


Package Input-Output: 
Package Text-I0O: 

Get: 

Ute 

Read: 

Write: 

Package Low-level-ID: 
Send-Control: 
Receive-Control: 


Supported 
Not Supported 
Partially Supvorted 
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